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 [email protected]<mailto:[email protected]> 434-924-0640 From: gpfsug-discuss <[email protected]> on behalf of Talamo Ivano Giuseppe <[email protected]> Reply-To: gpfsug main discussion list <[email protected]> Date: Thursday, September 14, 2023 at 3:19 PM To: "[email protected]" <[email protected]> Subject: Re: [gpfsug-discuss] Unexpected permissions with ACLs ________________________________ From: gpfsug-discuss <[email protected]> on behalf of Christof Schmitt <[email protected]> Sent: 14 September 2023 18:02 To: [email protected] <[email protected]> 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
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org
