Thank you both, now I have a clearer picture.
Actually, the ACL and umask interaction was unclear to me. Reading around I
also found some reference in the man page of the open syscall ("in the absence
of a default ACL, the mode of the created file is (mode & ~umask)").
Cheers,
Ivano
__________________________________________
Paul Scherrer Institut
Ivano Talamo
WHGA/038
Forschungsstrasse 111
5232 Villigen PSI
Schweiz
Phone: +41 56 310 47 11
E-Mail: [email protected]
________________________________
From: gpfsug-discuss <[email protected]> on behalf of Christof
Schmitt <[email protected]>
Sent: 15 September 2023 01:44
To: [email protected] <[email protected]>
Subject: Re: [gpfsug-discuss] Unexpected permissions with ACLs
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
