Chmod overiding default ACLs.

Linux and Unix-Like Red Hat
1

Afternoon all,

This should be a simple task.

I have set up default acls on a directory to allow user user1 to read it. This directory is owned by root:root.

setfacl -d -m u:user1:rx /directory

I also did via the group.

This works fine, new files made by root are readable.

getfacl /directory supports this:
 
...
default:user:user1:r-x
...
default:group:user1:r-x

However, the process that is writing new files is writing them as 700, and this user cannot read those files.

getfacl /directory/newfile gives:
 
#file: newfile
#owner: root
#group: root
user::rwx
user:user1:r-x                           #effective:---
group::r-x                                 #effective---
group:user1:r-x                         #effective----
mask::r-x
other::r-x

This occurs also if you create a file that is readable, then chmod 700.

Can some explain the effective rights for me and why its overiding the acls where the files are either chmod 700, or written as 700 by the process that is writing them? I know this is the correct behaviour, I am just trying to understand why this is.

Cheers,
Si :smiley:

2

Have you tried setting the umask?

3

I have the same on AIX (slightly different commands) and that is just how it works. The safest way to change such files is by editing the ACL. What you are saying with your chmod is "Overwrite the security permissions with RWX --- ---" so that's what it does. Everything else is invalidated.

perhaps you may have more success with the other format of chmod where you specifically grant/revoke accesses:-

chmod u+r file
chmod u+w file
chmod u+x file
chmod g-r file
chmod g-w file
chmod g-x file
chmod o-r file
chmod o-w file
chmod o-x file

I've never tried this, and you may be able to combine them, but the basically system is doing what you ask it to.

I hope that this helps

Robin
Liverpool/Blackburn
UK

4

Sorry, should have stated, I have no control over what is changing the files. They are written by a process nightly, the acls are to allow auditing via splunk. But new files are no taking the default ACL as they are being written as 700, or at least written as something else and the chmodded to 700. Eitherway, the default ACLs set on that directory are not working for the new files, and splunk can cannot read the new files, but can on everything else in the directory. I can fix with cron, but it doesn't seem very elegant :slight_smile:

5

As far as I recall, using POSIX commands such as chmod overwrite any previous ACLs on a file and create a new ACL with entries only for owner, group and everyone.