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