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@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
--
J Martin Rushton MBCS
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
