I have a VPS and use it for hosting my sites. The server is nginx with php-fdm.
my site is in the /var/www/sitename/html/ and all the files and folders under the html directory owned by www-data www-data. All files permision is 664 and directories (html folder and sub-directories) has 775 permission. And also my user is member of the www-data group.
I can change every files in this folder, but I can't make new file or new folder here. This need sudo privileges. I can create new file in the sub-directories like /var/www/sitename/html/uploads but not in the /var/www/sitename/html/ while they have the same owner and permission.
The user you are logging in as is not the www-data user or a member of the www-data group.
I set things up on my servers so that the user I log in as owns the files/directories, and a webuser group is the owning group, perms are set to 750/640. You can automagically keep the owning group the same across all files/directories uploaded to/created on the server by making the top level web directory setgid.
drwxr-s--- 4 debbie www-data 4096 Oct 6 2015 /var/www-debbie.example.com
If the webserver needs to write files, create the directory and change the permissions on it
sudo mkdir /var/www-debbie.example.com/writeable
sudo chmod 770 /var/www-debbie.example.com/writeable
If you haven't done the setgid thing, then fix the ownership
sudo chown debbie.www-data /var/www-debbie.example.com/writeable
And there ya go, the web server user can write to it.
drwxrws--- 4 debbie www-data 4096 Oct 6 2015 /var/www-debbie.example.com/writeable
Related
We are getting the error "permission denied" when trying to write to a file that is owned by a service user and a shared group. In particular that is www-data:www-data and the user trying to write to it is in the group www-data.
There is no acl on none of the parent folders and the permissions to the file and folders are correct.
Here some details:
$ sudo -u deploy id -Gn
www-data
$ ls -lah /tmp
drwxrwxrwt 17 root root 4.0K Jul 11 11:22 .
drwxr-xr-x 23 root root 4.0K Jul 8 10:08 ..
...
-rw-rw-r-- 1 www-data www-data 0 Jul 11 10:50 test
...
$ echo 'hello world' | sudo -u deploy tee -a /tmp/test
tee: /tmp/test: Permission denied
hello world
we tried that on different folders and made sure there is no acl on any of the folders or parents or files...
Unfortunately that is not described in the link stark posted in the comment. And also not in any other page I found until I found an answer here on stackoverflow that clarified it.
2018 two new filesystem configurations got added to sysctl that should prevent regular files and fifos from beeing opened with the O_CREAT flag (as append mode is doing) in directories with the sticky bit set unless the user is the owner of the file. This commit added the settings: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5
To change that behaviour you have to set fs.protected_regular to 0:
sudo sysctl fs.protected_regular=0
Or to persist the change add fs.protected_regular=0 to your sysctl.conf.
side node: since O_CREAT is not deleting or renaming the file I'm wondered why it is connected to the sticky bit. It really is possible to create a file in directories with the stick bit set.
+x Permission is provided for user and directory is owned by the user.
drwxr-xr-x. 3 www-data www-data 19 Nov 30 10:41 www
Still, I am unable to access the directory.
www-data is Nginx and PHP-fpm user. When I try su www-data I can't access any directory inside /var although I can do cd /var.
You can check if this account has a login access, by checking items in /etc/passwd.
If it has a "nologin", you can't login with this us
Two directories have the same permissions like this
drwxrw-rw- 2 user_1 users 4096 May 10 23:03 lg-x1
drwxrw-rw- 2 user_1 users 4096 May 11 17:22 lg-c2
when access lg-x1 with user_1, it shows: '-hash cd: lg-x1: Permission denied' ;
but lg-c2 is accessable.
Both lg-x1 and lg-c2 are accessable when login with root.
what's the difference?
In order to access a directory in Linux you need execute permissions. Only root has it, therefore other users cannot access it. Add x with the relevant sudo chmod you need
I am a linux newbie and I have a very basic question. I have one machine which is machineA and I have a root access to that machine.
Now I need to create these below two directories and give permissions to app user.
Create ZooKeeper Data directory and give permissions to app : /opt/zookeeper/data
Create ZooKeeper Log directory and give permissions to app : /opt/zookeeper/log
I have already created those directories in /opt folder by logging as root -
root#machineA:/opt# ls -lt
drwxr-xr-x 4 root root 4096 Dec 17 13:46 zookeeper
root#machineA:/opt/zookeeper# ls -lt
drwxr-xr-x 2 root root 4096 Dec 17 13:46 log
drwxr-xr-x 2 root root 4096 Dec 17 13:45 data
Now I am not sure how to give permissions to app user as mentioned above? I believe this is pretty easy question but I am not sure how to do that?
Any thoughts?
Here you go:
chown -R app /opt/zookeeper
This will change owner of the /opt/zookeeper directory and all its subdirectories to app.
Use chown to change the owner of a file (or directory):
chown app log data
I have set up an Amazon EC2 instance. By default my apache is running as user apache of the group apache.
I created new ftp user test and uploaded my files to /home/test/public_html. I then configured the virtual host DocumentRoot to point to my project, residing in /home/test/public_html.
When the directory is owned by user test, uploading in the project is denied: it gives a permission error. If I change the owner of the directory to apache, it works.
How can give the apache user superuser rights, to permit it to upload without changing the directory's owner?
It's always same problem. Upload with user ftp and no access for user apache.
I solved that problem using filesystems extended acls.
It's possible to put a 'default' user and/or group to new generated files.
What you have to do:
add 'acl' to your mount options for your desired filesystem. (Please check if your kernel is configured for posix acl before doing so!)
use command 'setfacl' to set permissions (you may need to install a package containing 'setfacl' before depending on your distribution.)
Example:
First own for user ftp so uploads can be made
# chown ftp:ftp /var/www/server/htdocs
# ls -la /var/www/server/htdocs/
insgesamt 0
drwxr-xr-x 2 ftp ftp 40 26. Nov 12:40 .
drwxrwxrwt 15 root root 360 26. Nov 12:40 ..
Next set default for user apache
# setfacl -d -m u:apache:rwx /var/www/server/htdocs
# setfacl -d -m g:apache:rwx /var/www/server/htdocs
# getfacl /var/www/server/htdocs
# file: /var/www/server/htdocs
# owner: ftp
# group: ftp
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:apache:rwx
default:group::r-x
default:group:apache:rwx
default:mask::rwx
default:other::r-x
After putting files or directorys to this directory you will see that you have multiple accessrights to them. But keep in mind that those rights are only given to new files not to existing once.
# getfacl /var/www/server/htdocs/test.txt
# file: /var/www/server/htdocs/test.txt
# owner: ftp
# group: ftp
user::rw-
user:apache:rwx #effective:rw-
group::r-x #effective:r--
group:apache:rwx #effective:rw-
mask::rw-
other::r--
When using 'ls -l' you see a '+' after the permissions to inform about acl rights:
# ls -la /var/www/server/htdocs
insgesamt 0
drwxr-xr-x+ 3 ftp ftp 80 26. Nov 12:43 .
drwxrwxrwt 15 root root 360 26. Nov 12:40 ..
drwxrwxr-x+ 2 ftp ftp 40 26. Nov 12:43 test
-rw-rw-r--+ 1 ftp ftp 0 26. Nov 12:43 test.txt
I would at all cost avoid letting apache user have root privileges.
This would be quite a serious security issue: exactly because the server is potentially (more) vulnerable you normally make a specifc user for it (here the 'apache' user) where you can specify the privileges to only those that are really needed for the server run.
If there are problems with the Apache user not having all the right permissions you should solve them by changing the ownership of corresponding files to apache user,
chown apache:apache <filename>
or, by making them readable/writable/executable for more users, e.g. using
chmod 777 <filename>