I have a user didongo (user & group didongo), and the nginx server (user & group www-data). I've setup Capifony to login as didongo user: the first time I deploy setfacl command works ok (while the logs folder is empty). But after the web application, served by nginx, has generated some logs (prod.log) the very next deploy fails, with an setfacl error.
I'm sure I'm doing a noob error with the permissions between the user and the web server, but I don't see what error. I see that didongo should not be able to change permissions of a file he hasn't permissions to. But then, how I'm supposed to configure the server or Capifony?
Thanks!
Relevant (hope so) Capifony deploy.rb config:
set :user, "didongo"
set :webserver_user, "www-data"
set :permission_method, :acl
set :use_set_permissions, true
set :shared_children, [app_path + "/logs", web_path + "/uploads", "vendor"]
set :writable_dirs, ["app/cache", "app/logs"]
This is the Capifony error:
$ setfacl -R -m u:didongo:rwx -m u:www-data:rwx /home/didongo/staging/shared/app/logs
setfacl: /home/didongo/staging/shared/app/logs/prod.log: Operation not permitted
Some data on the ACL:
$ getfacl app/logs
# file: logs
# owner: didongo
# group: didongo
user::rwx
user:www-data:rwx
user:didongo:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:www-data:rwx
default:user:didongo:rwx
default:group::rwx
default:mask::rwx
default:other::r-x
# file: logs/prod.log
# owner: www-data
# group: www-data
user::rw-
user:www-data:rwx #effective:rw-
user:didongo:rwx #effective:rw-
group::rwx #effective:rw-
mask::rw-
other::r--
Try this once with sudo and after you will no need to use sudo
sudo sh -c 'setfacl -R -m u:didongo:rwX -m u:www-data:rwX /home/didongo/staging/shared/app/logs'
Because you need to set x+ permissions, read this What is trailing Plus indicates
The problem here, is that prod.log file was created automatically so its owner is www-data. Capifony runs deployment as didongo user. One user can't do setfacl to the other owner's file.
So just add didongo to the group www-data: sudo adduser didongo www-data
Finally I managed this creating different PHP-FPM pools with the same permissions as the user. This way I can have different users separated from each other. And as a bonus deploy.rb is simplified.
Related
Our web development setup on Ubuntu 20.04 looks as follows:
We run Apache as www-data (pretty standard)
The user logs in as "dev" (for example)
So PHPStorm runs as dev
This usually leeds to the problem, that CLI commands (such as building the Theme) and actions via the web interface (such as changing Theme colors in the Admin Panel) clash with file permissions when for example the CLI creates a file which Apache later tries to change.
For years (i.e. with Magento 2, Contao, Laravel, ... before we started working with Shopware 6) we went well with the following command in the projects folder, using Linux ACLs:
export FOLDER=projects && sudo setfacl -Rm u:$USER:rwx $FOLDER && sudo setfacl -Rm u:www-data:rwx $FOLDER && sudo setfacl -Rm d:u:$USER:rwx $FOLDER && sudo setfacl -Rm d:u:www-data:rwx $FOLDER && sudo chmod 600 config
So ACLs are set properly and access works for the webserver as well as CLI commands .
And then came Shopware.
When building or changing the theme, the underlying Flysystem tries to set the visibility of files (the permissions). And while you can read/write files properly with the setfacl trick above, chmod is only possible for the file owner (which is "dev").
So we are getting:
detail: "Warning: chmod(): Operation not permitted"
meta: {trace: [,…], file:
"/home/dev/projects/example.com/vendor/league/flysystem/src/Adapter/Local.php",
We are wondering what is an elegant solution for this? How are others solving this?
Approaches we are considering:
letting apache run under the same user as the logged in user
doing CLI tasks as www-data
switching to docker and also use www-data scope for everything
We decided to run Apache and FPM processed unter the logged in user. To avoid security issues, Apache should first be bound to 127.0.0.1:
in /etc/apache2/ports.conf
Listen 127.0.0.1:80
Listen ::1:80
<IfModule ssl_module>
Listen 127.0.0.1:443
Listen ::1:443
</IfModule>
Next, in /etc/apache2/envvars we set the variables APACHE_RUN_USER and APACHE_RUN_GROUP to the logged in user dev.
For FPM we set in all /etc/php/*/fpm/pool.d/www.conf
user = dev
group = dev
listen.owner = dev
listen.group = dev
Finally we restart apache and FPM processed and make sure the project files are owned by the logged in user.
You also might want to delete old sessions of the www-data user (or chown them)
sudo rm /var/lib/php/sessions/*
I am install nfs using this command in fedora 32:
sudo dnf install nfs-utils
and then I create a dir to export storage:
[dolphin#MiWiFi-R4CM-srv infrastructure]$ cat /etc/exports
/home/dolphin/data/k8s/monitoring/infrastructure/jenkins *(rw,no_root_squash)
now I could mount this dir with root user like this:
sudo mount -t nfs -o v3 192.168.31.2:/home/dolphin/data/k8s/monitoring/infrastructure/jenkins /mnt
now I want to make a step forward to make it it avaliable to any user from any ip(the client could mount nfs without using sudo), so I first try to chown of this folder:
chown 777 jenkins
and then I want to make this jenkins folder group and user to nfsnobody:
[dolphin#MiWiFi-R4CM-srv infrastructure]$ chown -R nfsnobody jenkins
chown: invalid user: ‘nfsnobody’
and I do not find any nfsnobody content from /etc/passwd. what should I do to fix invalid user: ‘nfsnobody’ problem? should nfs-util added it automatically?
Right now nobody used by default probably after RedHat/Centos versions 8
You can simply use
chown -R nobody jenkins
Or
Change it from /etc/idmapd.conf
[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody
To put the changes into effect restart the rpcidmapd service and remount the NFSv4 filesystem:
service rpcidmapd restart
mount -o remount /nfs/mnt/point
On Red Hat Enterprise Linux 6, if the above settings have been applied and UID/GID’s are matched on server and client and users are still being mapped to nobody:nobody then a clearing of the idmapd cache may be required.
# nfsidmap -c
I have a problem whith my installation of docker. When I launch my docker-compose up I have this error :
front_1 | /var/lock/apache2 already exists but is not a directory owned by www-data.
front_1 | Please fix manually. Aborting.
I have this error because I add this line in my dockerfile conf :
RUN usermod -u 1000 www-data
But if I delete this line, my symfony project doesn't work with docker.
Do you have any ideas to solve my problem ?
Best regards
As I see it, you are trying to change UID of user www-data inside docker to have the same ID as host machine user UID (you), so you can open project files in your IDE.
This introduces file permissions problems on apache2 service, which can't read it's own files (config, pid,...), simply because it is not the same user anymore.
Quick 'dirty' solution is to change only owner of symfony project files to UID 1000, but keep group (GID) to the www-data. This applies only for dev machine. Else you don't needed it. Run command inside container.
chown -R 1000:www-data /home/project
You can create some bash alias inside docker to have it at hand.
Other option is to use ACL which will set existing files and folder with permissions, which will get inherited to newly created files under given folder. This could be put to bootstrap script inside container. But only for DEV mode. This way you won't need to run chown.
chown -R 1000:www-data /home/project #set for existing files
/usr/bin/setfacl -R -m u:www-data:rwx -m u:0:rwx -m u:1000:rwx /home/project
/usr/bin/setfacl -dR -m u:www-data:rwx -m u:0:rwx -m u:1000:rwx /home/project
Each -m is for a different user. First is www-data (apache2), second is 0 (root) and third is 1000 (you).
Remember UID can change anytime. So this could create security hole if mentioned users are not having proper UID.
I used second method only for folders, where PHP via apache2 sets permissions (uploaded files, cache,...), but host user needs to access these files.
Trying to install my CakePHP based application on server, but got following error:
Warning: _cake_core_ cache was unable to write 'cake_dev_en-us' to File cache in /var/www/html/cakephp-2460/lib/Cake/Cache/Cache.php on line 325
Warning: /var/www/html/tmp/cache/persistent/ is not writable
Sounds simple, but it is not - because my 'persistent' directory IS writable - in fact, /tmp and it's sub directories are writable.
Can you point me where is the problem? Do I missing some of PHP modules on server, or something like that?
Is there something to do with SeLinux?
Check that the user group for that directory is correct.
Maybe the user owner group does not have root permissions and therefor cannot write.
you may need to do the following on your server:
chown root:root -R /path_to_cake/app/tmp
Yes it is the problem in your SeLinux.You have to set www/..path../tmp directory is a httpd_cache_t so opan your terminal and
list to see all httpt_cache_t in system
# semanage fcontext -l | grep httpd
Set your www/.../tmp directory
# semanage fcontext -a -t 'httpd_cache_t' 'www/..path../tmp(/.*)?'
# restorecon -Rvvv /path/to/wwwroot/cache
I have set up a Linux Server and installed Apache and SVN and dav_svn on it. Now, when I try to upload to https://x.x.x.x:x/svn/repo with Tortoise SVN I get
Can't open file '/server/svn/repo/db/txn-current-lock': Permission denied
I have Set up my SSL correctly (I can checkout, no problems, even remotely due to Port Forwarding).
I'm guessing this has to do with the Linux Ownership of the Repository folders, How must I set this/ what are the commands?
This is a common problem. You're almost certainly running into permissions issues. To solve it, make sure that the apache user has read/write access to your entire repository. To do that, chown -R apache:apache *, chmod -R 664 * for everything under your svn repository.
Also, see here and here if you're still stuck.
Update to answer OP's additional question in comments:
The "664" string is an octal (base 8) representation of the permissions. There are three digits here, representing permissions for the owner, group, and everyone else (sometimes called "world"), respectively, for that file or directory.
Notice that each base 8 digit can be represented with 3 bits (000 for '0' through 111 for '7'). Each bit means something:
first bit: read permissions
second bit: write permissions
third bit: execute permissions
For example, 764 on a file would mean that:
the owner (first digit) has read/write/execute (7) permission
the group (second digit) has read/write (6) permission
everyone else (third digit) has read (4) permission
Hope that clears things up!
It's permission problem. It is not "classic" read/write permissions of apache user, but selinux one.
Apache cannot write to files labeled as httpd_sys_content_t they can be only read by apache.
You have 2 possibilities:
label svn repository files as httpd_sys_content_rw_t:
chcon -R -t httpd_sys_content_rw_t /path/to/your/svn/repo
set selinux boolean httpd_unified --> on
setsebool -P httpd_unified=1
I prefer 2nd possibility. You can play also with other selinux booleans connected with httpd:
getsebool -a | grep httpd
I also had this problem recently, and it was the SELinux which caused it.
I was trying to have the post-commit of subversion to notify Jenkins that the code has change so Jenkins would do a build and deploy to Nexus.
I had to do the following to get it to work.
1) First I checked if SELinux is enabled:
less /selinux/enforce
This will output 1 (for on) or 0 (for off)
2) Temporary disable SELinux:
echo 0 > /selinux/enforce
Now test see if it works now.
3) Enable SELinux:
echo 1 > /selinux/enforce
Change the policy for SELinux.
4) First view the current configuration:
/usr/sbin/getsebool -a | grep httpd
This will give you: httpd_can_network_connect --> off
5) Set this to on and your post-commit will work with SELinux:
/usr/sbin/setsebool -P httpd_can_network_connect on
Now it should be working again.
for example on debian
sudo gpasswd -a svn-admin www-data
sudo chgrp -R www-data svn/
sudo chmod -R g=rwsx svn/
I just had this problem
Having multiple user using the same repo caused the problem
Logout evey other user using the repo
Hope this helps
In addition to the repository permissions, the /tmp directory must also be writeable by all users.
3 Steps you can follow
chmod -R 775 <repo path>
---> change permissions of repository
chown -R apache:apache <repo path>
---> change owner of svn repository
chcon -R -t httpd_sys_content_t <repo path>
----> change SELinux security context of the svn repository
Try to disable SELinux by this command /usr/sbin/setenforce 0. In my case it solved the problem.