Problem with setup specific permissions for folders/files via ACL rights under Debial Linux 9.5 - linux

please I want to ask you about setting specific permissions for files and folders via ACL rights under Linux. I have got problem with setup permissions for files. Folders works correctly.
I have got folder:
/test (with permissions -> chmod 777 /test)
Next setup was:
setfacl -d -m u::rwx /test
setfacl -d -m g::rwx /test
setfacl -d -m o::rwx /test
**result:**
file: test
owner: root
group: root
user::rwx
group::rwx
other::rwx
default:user::rwx
default:group::rwx
default:other::rwx
Now, when I create folder all is ok:
mkdir data
drwxrwxrwx+ 2 root root 4096 May 18 13:29 data
But when I create any file, I have got file only with rw-,rw-,rw-
touch data.txt
-rw-rw-rw- 1 root root 0 May 18 13:30 data.txt
Could you please tell me what I doing wrong ? I need to create new files with rwx,rwx,rwx
Thank you very much.

Related

Unable to write to a file with group permissions

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.

Remove www-data owned file using ordinary user

i have a folder which contain uploaded file. for example /var/www/app/storage/public :
ls -al /var/www/app/storage/public
-rw-r--r-- 1 www-data www-data 835870 Aug 22 13:42 8b4c4e2a3d64.pdf
-rw-r--r-- 1 www-data www-data 835870 Aug 22 13:24 3d326ab2b3bc.pdf
I want to make a script to clean up that directory without using root user. What should i do if i want to delete those files using ordinary user like sanders so i can do something like:
sanders#localhost:~$ rm -rf /var/www/app/storage/public
Thank you :)
You will have to add this user to your "www-data" group:
sudo usermod -a -G www-data sanders
Then, make sure your folders have the correct group permissions:
sudo chgrp -R www-data /var/www/app/storage/public
sudo chmod -R g+w /var/www/app/storage/public

ec2-user does not has permission to write to web folder

I created an apache web server using CFT; this is using RHEL 7. In order to allow ec2-user to modify files in apache document root folder, I added the following in CFT (taken from var/log/cloud-init.log)
Jun 30 16:11:15 ip-10-205-0-135 cloud-init: groupadd www Jun 30 16:11:16 ip-10-205-0-135 cloud-init: usermod -a -G www ec2-user Jun 30 16:11:16 ip-10-205-0-135 cloud-init: chown -R root:www /var/www Jun 30 16:11:16 ip-10-205-0-135 cloud-init: chmod 2775 /var/www Jun 30 16:11:16 ip-10-205-0-135 cloud-init: find /var/www -type d -exec chmod 2775 {} \; Jun 30 16:11:16 ip-10-205-0-135 cloud-init: find /var/www -type f -exec chmod 0664 {} \;
As you can see from log, this went fine. However, when logged under ec2, it gives permission error as below:
[ec2-user#ip-10-206-32-92 html]$ aws s3 sync s3://gfrepo/releases releases download failed: s3://gfrepo/releases/binaries.html to releases/binaries.html [Errno 13] Permission denied: u'/var/www/html/releases/binaries.html' download failed: s3://gfrepo/releases/B1556013/B1556013.jar to releases/B1556013/B1556013.jar Could not create directory /var/www/html/releases/B1556013: [Errno 13] Permission denied: '/var/www/html/releases/B1556013'
I ended up elevating my permission as sudo to complete s3 sync. Not sure why it's giving permission error for ec2-user. Here are the listing of the permissions:
[ec2-user#ip-10-206-32-92 www]$ ls -l total 0
drwxrwsr-x. 2 root www 6 Mar 21 02:33 cgi-bin
drwxrwsr-x. 3 root www 55 Jun 30 16:11 html
[ec2-user#ip-10-206-32-92 www]$ groups ec2-user
ec2-user : ec2-user adm wheel systemd-journal www
As you can see ec2-user is part of www group and www is the owner of html sub-dir
You have to make sure the ec2-user belongs to the group that has write permission
if the directory /var/www/html is owned by root it will not let you write to the folder.
first do you an ls -l on /var/www/html
find out what's the group name, it's next to user
then issue this command
sudo usermod -a -G www ec2-user
You need to add ec2-user to the www group
You're logged in ec2-user, although you're issuing an aws s3 sync command, you need permission to write to the permissible directory, that's why it's failing.
This directory /var/www/html/releases/ does not have the permission.
Could not create directory /var/www/html/releases/B1556013 <----
or su to root and try the command.

Linux file permissions

I have two questions regarding linux file permissions.
1)
I have the directory /share with the following permissions:
[root#localhost ~]# ls -ld /share/
drwxrwxrwx. 4 root root 4096 Aug 29 09:15 /share/
Now I go as user erich to that directory and create a file:
[erich#localhost share]$ touch file
[erich#localhost share]$ ls -l
-rw-r--r--. 1 erich share 0 Aug 29 09:30 file
Now as user sven I delete the file:
[sven#localhost share]$ rm -f file
[sven#localhost share]$
How is that possible? Only erich has read/write permissions. I noticed that when I change the /share folder's permission to e.g. 755, then sven cannot delete the file. Is the parent's directory overwriting the files' permissions in it and if yes, why?
2)
I want to share that /share folder to everybody, but at least for sven and erich. I created a group "share" and put those users in it. Then I did the test:
[erich#localhost share]$ mkdir erich
[erich#localhost share]$ ls -l
drwxr-xr-x. 2 erich share 6 Aug 29 09:28 erich
[erich#localhost share]$ touch erich/erich
[erich#localhost share]$ ls -l erich/
-rw-r--r--. 1 erich share 0 Aug 29 09:28 erich
User sven has no write permission to "file". How can I fix that?
Despite the fact that directory permissions are named in the same way, they are kind of different from the file permissions.
For folder:
r is for listing content of the folder
w for creating and deleting files
x for making that directory current (cd in it).
That's why user can delete file with w switched on, even if it has no write permission for the file itself.
Directory permissions doesn't force permission on file you create within it; so, after you create file with touch, you should make it group-writable. You can change permissions of all files in the directory with chmod 775 -R share (-R means recursively).

How can I allow my apache user to upload to user directory when using Apache on EC2?

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>

Resources