[gpfsug-discuss] NF4 ACLs
Joshua Taylor
joshua.taylor at psi.ch
Mon Sep 5 14:43:15 BST 2022
Hi Again -
@Alec - thanks! this helped clarify things quite a bit.
However, with some experimenting, i was able to understand the "CHOWN"
part. The user with the chown permission is not able to give ownership
arbitrarily to any other user - they are only able to take ownership of
the file.
that is: given userX and userY, userY writes a file (is default owner)
where file inherits ACL for userX to chown. UserX can only 'chown userX
file' - essentially give ownership to themselves. They can not give
ownership back to userY. There may be groups and group ACLs involved
which complicate this even further, however I wasn't able to test that.
This is to say the "CHOWN" permission is not 'global', like root would
have. This might be useful for future documentation updates, as would
delineating the difference between ACLs for files and ACLs for
directories in relation to the standard posix umask file creation (@IBM).
Thanks again to everyone for helping with this!
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
On 9/2/22 12:32, Taylor Joshua George (PSI) wrote:
> 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
>>>> <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
>>>> <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
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at gpfsug.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org
More information about the gpfsug-discuss
mailing list