I want files created by Apache to have 660 permissions, so I added the line "umask 007" to the file "/etc/sysconfig/httpd" and it works MOST of the time (as weird as that sounds).
For example, these files were created by Apache and the first one has the correct permissions, but the others don't.
-rw-rw---- 1 apache psacln 0 Aug 4 17:20 timthumb_cacheLastCleanTime.touch
-rw------- 1 apache psacln 124670 Aug 4 17:46 timthumb_int_00d3cbe9ad96f30121f17bbe1a92b42e.timthumb.txt
-rw------- 1 apache psacln 290077 Aug 4 18:27 timthumb_int_02d34e93c41599570c5302d6a08c8ba6.timthumb.txt
I'm not sure what to look for in order to fix this as it seems the UMASK setting is being ignored for some files. The problem here is that the FTP user (member of the psacln group) can't read the files that don't have group read permissions (because for security reasons I don't want to give permissions to "others").
Let me know if you have any idea why this may be happening.
umask controls which file permissions are set for files and directories when they are created. Most probably there is a code that is changing the permissions after the creation.
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.
I have two groups manually created in /etc/group:
file-owner:x:300:user
user:x:400:
I have a configuration file, owned by the user/group file-owner. I don't want other users to read it.
ls -l /tmp/my-configs.txt
-r--r----- 1 file-owner file-owner 1054552 Jun 11 12:22 /tmp/my-configs.txt
I run a process with id user:user but I cannot read the configuration file owned by file-owner.
Am I doing something wrong?
I can see my below folders having dot at the end of permissions
drwxr-xr-x. 2 root root 4096 May 26 2010 java-1.7.0
drwxr-xr-x. 2 root root 4096 May 26 2010 java-1.6.0
drwxr-xr-x. 2 root root 4096 May 26 2010 java-1.5.0
How can I create a new folder with similar permissions ?
I found a way to do it, in case anyone needs it.... posting answer :
[root#XXXXX share]# chcon -h system_u:object_r:usr_t:s0 java-1.8.0
[root#XXXXXXshare]# ls -dZ java-1.8.0
drwxr-xr-x. root root system_u:object_r:usr_t:s0 java-1.8.0
A good read: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html
you are using a Redhat based distro, that means selinux permissions, you can use:
ls -lZ
From man page
man ls
-Z, --context
print any SELinux security context of each file
If you want to use Selinux, you can start from here
Selinux permissions are a big topic.
I have the following problem, I run a script on multiple servers that writes files on a single server.
Files are written with these rights:
-rw-r--r-- 1 someuser someuser 139 Apr 2 12:40 filename.jpg
What I would like to do would be to be able to delete this file via a php script that runs with www-data rights.
Is there a way to configure something so www-data is allowed to remove the above file?
The php script run wiht user (euid): www-data and group (egid): www-data.
One solution may be the following:
-rw-rw-r-- 1 someuser www-data 139 Apr 2 12:40 filename.jpg
In this situation, the php script could delete the file without problems.
My crontab isn't running and I'm trying to figure out why. I've created a symbolic link within /etc/cron.d to /var/www/mysite.crontab
user#ip-xxxxxxxxxx:/etc/cron.d$ ll
total 20
drwxr-xr-x 2 root root 4096 Apr 11 03:48 ./
drwxr-xr-x 96 root root 4096 Apr 16 00:50 ../
lrwxrwxrwx 1 root root 30 Apr 11 03:47 mysite.crontab -> /var/www/mysite.crontab
-rw-r--r-- 1 root root 124 Feb 27 2012 drupal7
-rw-r--r-- 1 root root 544 Sep 12 2012 php5
-rw-r--r-- 1 root root 102 Apr 2 2012 .placeholder
The actual cron file is...
#Purge old deals
4 1 * * * www-data wget -q -O- http://www.mysite.com/cron/clean > /dev/null 2>&1;
Oddly enough the problem is with the name of the file. You are not permitted to use a . as a part of the name of the file when present in the /etc/cron.d dirctory.
The logic for this is in the database.c file, in the function valid_name. Renaming the file to something like mysite_crontab should fix the issue.
In general, the filename should probably just be a simple name mysite the fact that it's in this directory implies that it's a cron file already.
The file that is being pointed to must be owned by root, this is stated in the man page for the support of the /etc/cron.d directory:
Support for /etc/cron.d is included in the cron daemon itself, which handles this location as the system-wide crontab spool. This directory can contain any file defining tasks following the format used in /etc/crontab, i.e. unlike the user cron spool, these files must provide the username to run the task as in the task definition.
Files in this directory have to be owned by root, do not need to be executable (they are configuration files, just like /etc/crontab) and must conform to the same naming convention as used by run-parts(8): they must consist solely of upper- and lower-case letters, digits, underscores, and hyphens. This means that they cannot contain any dots. If the -l option is specified to cron (this option can be setup through /etc/default/cron, see below), then they must conform to the LSB namespace specification, exactly as in the --lsbsysinit option in run-parts.
The intended purpose of this feature is to allow packages that require finer control of their scheduling than the /etc/cron.{hourly,daily,weekly,monthly} directories to add a crontab file to /etc/cron.d. Such files should be named after the package that supplies them.