Thanks - that seems to make sense
I guess I was being over optimistic thinking default ACLs could help here :-)
Thanks
James Pearson
J Martin Rushton via CentOS wrote:
Look at the acl(5) man page and you'll see that the ACCESS CHECK ALGORITH starts:
IF the effective user ID of the process matches the user ID of the file object owner ...
ELSE IF the effective user ID of the process matches the qualifier of any entry of type ACL_USER, THEN IF the matching ACL_USER entry and the ACL_MASK entry contain the requested permissions, access is granted, ELSE access is denied. ELSE ...
The effective user ID is <user-b>. This matches an ACL_USER entry (user:user-b:r--) so therefore consider the ACL_MASK. It is "---" so does NOT contain the requested permission, and therefore access is denied.
Right, now we know why access is refused. Cast your eyes slightly further up the man page to OBJECT CREATION AND DEFAULT ACLS. Point 1 states that the object inherits the default ACL of the containing directory as its access ACL. So far so good, but point 2 states that the "file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter". What I suspect is happening is that the mode parameter is set during file creation and so the mask is cleared to ensure that the creator's wish overrides the directory default.
You need to either investigate the application (difficult, long winded), contact support (good luck), or find a way to live with it. Sudo is one solution, another is a script that does a setfacl -m m::rx logfile.
HTH,
Martin
On 14/05/2020 14:26, James Pearson wrote:
A bit of a minor off-topic issue, but on the off-chance that someone understands how ACLs work ...
I've been trying to see if using default ACLs would help with the following issue:
I have a third party application that is running as a non-root user ('user-a') and creating log files with mode 0600 (read/write only to the owner) in a log directory
I have another application that runs as another non-root user ('user-b') that needs to read the log files created by 'user-a'
I can't change the mode of the log files generated by 'user-a', but I thought I could add a default ACL to the log file's parent directory that gave read access to 'user-b' - i.e. something like:
% sudo setfacl -d -m u:user-b:r logdir % getfacl logdir # file: logdir # owner: user-a # group: user-a user::rwx group::r-x other::r-x default:user::rwx default:user:user-b:r-- default:group::rwx default:mask::rwx default:other::r-x
Now when new log files are created in logdir, the default ACL is inherited, but 'user-b' still can't read the files - i.e.
% getfacl logdir/logfile # file: logdir/logfile # owner: user-a # group: user-a user::rw- user:user-b:r-- #effective:--- group::rwx #effective:--- mask::--- other::---
i.e. the effective access for 'user-b' is '---' - which is no access to read for 'user-b'
I'm not sure where 'effective' comes from?
If I now explicitly add a read ACL for user-b to logdir/logfile:
% sudo setfacl -m u:user-b:r logdir/logfile % getfacl logdir/logfile # file: logdir/logfile # owner: user-a # group: user-a user::rw- user:user-b:r-- group::rwx mask::rwx other::---
and 'user-b' can read logdir/logfile
I guess I'm missing something on how default ACLs are meant to work - can anyone explain what is happening here or point me in the right direction ?
I've actually 'solved' the issue with a suitable sudoers rule that allows 'user-b' to run the required command as 'user-a', but I would like to find out why this default ACL method doesn't work
Thanks
James Pearson _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- J Martin Rushton MBCS _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos