[gpfsug-discuss] NF4 ACLs

Taylor Joshua George (PSI) joshua.taylor at psi.ch
Fri Sep 2 11:32:31 BST 2022


I'll give this a try!

Thank you! this helps clarify things a bit!

best,
Josh

On Fri, 2022-09-02 at 03:22 -0700, Alec wrote:
Hmm I think you're missing in what I sent that there are TWO ACE's for special owner@:
special:owner@:rwxc:allow:DirInherit
 (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:owner@:rw-c:allow:FileInherit: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        (-)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED

The first one sets up the new DIRECTORIES with exec/SEARCH.
The second one sets up the new FILES without EXEC/search.

This provides for new files to be made 660 while directories are created 2770.

I think you're conflating what the POSIX interface does with regards to a umask when a file is created versus what the ACL interface does when a file is created.  In fact the Open man page on Linux specifies that POSIX permissions are (mode & umask) in the ABSENCE of a default ACL.  NFS4 doesn't have a default ACL but the inheritance is an effective default ACL as it is copying the parent's ACL and building up from there.

Hope That Helps

Alec

On Fri, Sep 2, 2022 at 3:08 AM Alec <anacreo at gmail.com<mailto:anacreo at gmail.com>> wrote:
Taylor,
  What I provided would work for your use case 1000%... at the top level you'll need to add an entry for your process or a group that your process is a member of then it would be able to create files that the members of the sgid group have access to...

$ mmgetacl .
#NFSv4 ACL
#owner:someuser
#group:somegroup
special:owner@:rwxc:allow:DirInherit
 (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:owner@:rw-c:allow:FileInherit: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        (-)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED

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

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

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

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

You can decide in that last block how much control to give (or not give) on that file.  New files by "nongroupuser" would be owned by nongroupuser, but the group would be the group of the parent directory, not their primary group.

Alec

On Fri, Sep 2, 2022 at 2:50 AM Taylor Joshua George (PSI) <joshua.taylor at psi.ch<mailto:joshua.taylor at psi.ch>> wrote:
Perhaps I should try and describe my use-case a bit:

There is a daemon process that gets data and must then write it out
into a project directory in GPFS. The project directory is owned by the
project owner, and has the setgid bit set on the directory. This is so
that members of the group can read/write/etc files put in the
directory. The daemon is not a member of the project group.

The daemon process used to run as root, however, my goal with ACLs is
to enable it to write into project dirs, without needing to change the
effective UID/GID (or be a member of the group) - so, in this case, it
runs as a regular user. The ACL should allow it to write into the
project directory. Essentially, the ACL is to enable the daemon to run
as a regular user. Once the data is written, the Daemon will (likely)
never access the data again, only the users in the project.

So, my goal is to have the daemon write files owned by the project
Group (so, with g+rw), as the project users would just use the standard
posix permissions to access the data. I suppose I'm trying to blend the
use of ACLs and standard posix perms. More importantly, I'm trying to
get rid of the execute bit that new files are created with/inherited.

Answers to questions below...


On Fri, 2022-09-02 at 09:23 +0100, Jonathan Buzzard wrote:
> On 01/09/2022 22:18, Taylor Joshua George (PSI) wrote:
>
> >
> > Hi Everyone,
> > I'm trying implement some ACLs, however some of the documentation
> > is a
> > bit unclear to me.
> >
> > Using
>  >
> https://www.ibm.com/docs/en/spectrum-scale/5.1.4?topic=administration-setting-nfs-v4-access-control-lists
> > as a reference, I'm trying to understand what to use to achieve
> > 0660
> > permissions on files and 2770 on directories.
> >
>
> It's not clear from this whether you are trying to achieve the
> equivalent of 0660 and 2770 on files and directories or have an ls
> show
> the permissions as 0660 and 2770.

I'm trying to get the files to be created with 0660 perms (currently,
they are created 0770). I've tried playing with the `rwxc` in the first
line of the NFS4 ACL definition, with no luck (it seems to ignore that,
except for error checking). E.g. I've tried removing the `x`, which
passes the syntax check but doesn't seem to change anything.

so, daemon uses ACLs to write/create files, users use posix perms to
access/modify those files.

>
> > So far, I've managed to achieve 0000 perms, but user with the ACL
> > permission can chmod, or 0770 perms.
> >
>
> Basically neither of the above two options is possible because there
> is
> no exact mapping between POSIX permissions and NFSv4 ACL's.
>
> For example you can't get the equivalent of the set group id
> permission.
> You can however put an inheritable ACL for a group on the directory
> that
> gives r/w plus say search directory and possibly execute permissions
> if
> you want those as well.
>
> A user with ACL permissions can change permissions that is completely
> expected. Note that traditional 2770 permissions are only suggestive,
> the file or member of the group would be able to change them to
> something else. In fact programs often do when you save, and Samba
> just
> completely ignores them for the most part. At least with NFSv4 ACL's
> you
> can remove the ACL permission :-)
>
> How permissions display on an ls/stat is not an exact mapping and
> will
> tend to go to something like 0000, but actual ability to access etc.
> the
> file will be based on the ACL not what you see in ls/stat.
> > Attached is a txt file with the mmgetacl output, as well as file
> > listing on a test file, and finally, the ACL definition I used.
> >
> > As one can see in the attachment, the ACL requested appears
> > differently
> > for what it _actually_ applied.
> >
>
> What ACL schematics does the file system have? Is it NFSv4 or both?
>

It's pure NFSv4
-D       nfs4       File locking semantics in effect
-k       nfs4       ACL semantics in effect

>
> If you are wedded to POSIX style permissions perhaps change to POSIX
> ACL
> schematics on the file system?

I confess, I was hoping to mix the perms so as not to change our
processes too much. (we currently use reg. posix perms to enable group
writes [via sgid])

>
>
> JAB.
>

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org


--

Joshua Taylor

---
Paul Scherrer Institut
System Engineer
Science IT Infrastructure and Services department (AWI)
WHGA/038
Forschungstrasse 111
5232 Villigen PSI
Switzerlandd
+41 56 310 52 50

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20220902/dc77c6ef/attachment-0002.htm>


More information about the gpfsug-discuss mailing list