[gpfsug-discuss] Unexpected permissions with ACLs

[Christof Schmitt]

Yes. If there is one ACL entry that is inherited to a new file/directory, then only that inherited entry will be in the ACL of the new file/directory. The special case here is now that there is one inheritable entry, but that is flagged with DirInherit, so it does not apply to new files.

Regards,

Christof

On Thu, 2023-09-14 at 21:13 +0000, Losen, Stephen C (scl) wrote:
Hi, you have specified an inherited (inherit only) ACE in the parent directory’s ACL, so that disables umask. New files will only get whatever ACEs they inherit. Since the only inherited ACE pertains to directories and not files, a new file
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!2Y-vrJ9RxDnU-mYbFsElzTntwzTT-DfGSCnfv-QAUYaAOnlLm4fXFBf20DlV_V763N-syTtqyssyVlwdUuQ4A_i6JoPRMlLqcdY4sTzfjvU$>
Report Suspicious

ZjQcmQRYFpfptBannerEnd
Hi, you have specified an inherited (inherit only) ACE in the parent directory’s ACL, so that disables umask. New files will only get whatever ACEs they inherit. Since the only inherited ACE pertains to directories and not files, a new file inherits no ACEs, and hence ends up with zero permissions (which I suspect is no ACEs at all in its ACL).

So you need to specify some inherited ACEs for files as well as directories. Or else use FileInherit:DirInherit:InheritOnly

If the parent directory has no inherited ACEs in its ACL then the permissions on new files/directories are controlled by umask.

Steve Losen
Research Computing
University of Virginia
scl at virginia.edu<mailto:scl at virginia.edu>  434-924-0640

From: gpfsug-discuss <gpfsug-discuss-bounces at gpfsug.org> on behalf of Talamo Ivano Giuseppe <ivano.talamo at psi.ch>
Reply-To: gpfsug main discussion list <gpfsug-discuss at gpfsug.org>
Date: Thursday, September 14, 2023 at 3:19 PM
To: "gpfsug-discuss at gpfsug.org" <gpfsug-discuss at gpfsug.org>
Subject: Re: [gpfsug-discuss] Unexpected permissions with ACLs


________________________________
From: gpfsug-discuss <gpfsug-discuss-bounces at gpfsug.org> on behalf of Christof Schmitt <christof.schmitt at us.ibm.com>
Sent: 14 September 2023 18:02
To: gpfsug-discuss at gpfsug.org <gpfsug-discuss at gpfsug.org>
Subject: Re: [gpfsug-discuss] Unexpected permissions with ACLs
 > following:
>
> special:group@:rwx-:allow:DirInherit:InheritOnly
>  (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE
> (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
>  (-)DELETE    (X)DELETE_CHILD (X)CHOWN        (X)EXEC/SEARCH
> (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
>
> According to the manual, the DirInherit:InheritOnly should guarantee
> that the entry applies only to the new subdirectories but now it is
> also affecting new files in the main dir.
> Is this an expected behavior?

From an ACL perspective, yes. "InheritOnly" indicates that this entry
does not grant any permissions on the directory. It is only copied
as an entry to new files or subdirectories created in this directory.
So if this is the only ACL entry, there are indeed no permissions on
this directory.

You can remove the "InheritOnly" bit, then this would also grant
permission on the directory. Or you can add another ACL entry that
grants permissions on the directory.

I may have not been clear enough, but that ACE has only been added to the previous 3 ACEs, so the complete one for the directory is the following:

#NFSv4 ACL
#owner:root
#group:p15875
special:owner@:rwxc:allow
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (X)DELETE_CHILD (X)CHOWN        (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED

special:group@:rwx-:allow
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (X)DELETE_CHILD (X)CHOWN        (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED

special:everyone@:----:allow
 (-)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (-)DELETE_CHILD (-)CHOWN        (-)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED

special:owner@:rwx-:allow:DirInherit:InheritOnly
 (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL  (X)READ_ATTR  (X)READ_NAMED
 (-)DELETE    (X)DELETE_CHILD (X)CHOWN        (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED

So I would expect that the first 3 would still produce a 644 mode on the file. Am I wrong?
Cheers,
Ivano

_______________________________________________

gpfsug-discuss mailing list

gpfsug-discuss at gpfsug.org

<http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org>

http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20230914/83a019d8/attachment-0001.htm>