<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>I'll give this a try!</div>
<div><br>
</div>
<div>Thank you! this helps clarify things a bit!</div>
<div><br>
</div>
<div>best,</div>
<div>Josh</div>
<div><br>
</div>
<div>On Fri, 2022-09-02 at 03:22 -0700, Alec wrote:</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div dir="ltr">Hmm I think you're missing in what I sent that there are TWO ACE's for special owner@:
<div><span style="color:rgb(80,0,80);font-family:monospace"><span style="background-color:rgb(255,255,0)">special:owner@</span>:rwxc:allow:</span><span style="color:rgb(80,0,80);font-family:monospace">DirInherit</span><br style="color:rgb(80,0,80);font-family:monospace">
<span style="color:rgb(80,0,80);font-family:monospace"> (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED</span><br style="color:rgb(80,0,80);font-family:monospace">
<span style="font-family:monospace"><font color="#500050"> (-)DELETE (X)DELETE_CHILD (X)CHOWN
</font><span style="background-color:rgb(255,255,0)"><font color="#38761d">(X)EXEC/SEARCH</font></span><font color="#500050"> (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED</font></span><br style="color:rgb(80,0,80);font-family:monospace">
</div>
<div><span style="color:rgb(80,0,80);font-family:monospace"><br>
</span></div>
<div><span style="color:rgb(80,0,80);font-family:monospace"><span style="background-color:rgb(255,255,0)">special:owner@</span>:rw-c:allow:</span><span style="color:rgb(80,0,80);font-family:monospace;background-color:rgb(255,255,0)">FileInherit:InheritOnly</span><br style="color:rgb(80,0,80);font-family:monospace">
<span style="color:rgb(80,0,80);font-family:monospace"> (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED</span><br style="color:rgb(80,0,80);font-family:monospace">
<span style="font-family:monospace"><font color="#500050"> (-)DELETE (X)DELETE_CHILD (X)CHOWN
</font><span style="background-color:rgb(255,255,0)"><font color="#ff0000">(-)EXEC/SEARCH</font></span><font color="#500050"> (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED</font></span><br style="color:rgb(80,0,80);font-family:monospace">
</div>
<div><span style="color:rgb(80,0,80);font-family:monospace"><br>
</span></div>
The first one sets up the new DIRECTORIES with exec/SEARCH.<br>
The second one sets up the new FILES without EXEC/search.
<div><br>
</div>
<div>This provides for new files to be made 660 while directories are created 2770.</div>
<div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
<div>Hope That Helps</div>
<div><br>
</div>
<div>Alec</div>
</div>
<div><br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Sep 2, 2022 at 3:08 AM Alec <<a href="mailto:anacreo@gmail.com">anacreo@gmail.com</a>> wrote:<br>
</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div dir="ltr">Taylor,
<div> 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...</div>
<div><br>
</div>
<div><font face="monospace">$ mmgetacl .<br>
#NFSv4 ACL<br>
#owner:someuser<br>
#group:somegroup<br>
special:owner@:rwxc:allow:DirInherit<br>
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED<br>
(-)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED<br>
<br>
special:owner@:rw-c:allow:FileInherit:InheritOnly<br>
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED<br>
(-)DELETE (X)DELETE_CHILD (X)CHOWN (-)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED<br>
<br>
special:group@:rwx-:allow:DirInherit<br>
(X)READ/LIST (X)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED<br>
(X)DELETE (X)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED<br>
<br>
special:group@:rw--:allow:FileInherit:InheritOnly<br>
(X)READ/LIST (X)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED<br>
(X)DELETE (-)DELETE_CHILD (-)CHOWN (-)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED<br>
<br>
special:everyone@:----:allow:FileInherit:DirInherit<br>
(-)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (-)SYNCHRONIZE (-)READ_ACL (-)READ_ATTR (-)READ_NAMED<br>
(-)DELETE (-)DELETE_CHILD (-)CHOWN (-)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED</font><br>
</div>
<div><font face="monospace"><br>
</font></div>
<div>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New"">user:nongroupuser:rwx-:allow:DirInherit<span style="color:black;background:black"><u></u><u></u></span></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New"">(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (-)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED<span style="color:black;background:black"><u></u><u></u></span></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New"">(-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED</span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New""><br>
</span></p>
</div>
<div><span style="font-family:monospace">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.</span></div>
<div><br>
</div>
<div>Alec</div>
</div>
<div><br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Sep 2, 2022 at 2:50 AM Taylor Joshua George (PSI) <<a href="mailto:joshua.taylor@psi.ch" target="_blank">joshua.taylor@psi.ch</a>> wrote:<br>
</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div>Perhaps I should try and describe my use-case a bit:<br>
</div>
<div><br>
There is a daemon process that gets data and must then write it out<br>
into a project directory in GPFS. The project directory is owned by the<br>
project owner, and has the setgid bit set on the directory. This is so<br>
that members of the group can read/write/etc files put in the<br>
directory. The daemon is not a member of the project group.<br>
</div>
<div><br>
The daemon process used to run as root, however, my goal with ACLs is<br>
to enable it to write into project dirs, without needing to change the<br>
effective UID/GID (or be a member of the group) - so, in this case, it<br>
runs as a regular user. The ACL should allow it to write into the<br>
project directory. Essentially, the ACL is to enable the daemon to run<br>
as a regular user. Once the data is written, the Daemon will (likely)<br>
never access the data again, only the users in the project.<br>
</div>
<div><br>
So, my goal is to have the daemon write files owned by the project<br>
Group (so, with g+rw), as the project users would just use the standard<br>
posix permissions to access the data. I suppose I'm trying to blend the<br>
use of ACLs and standard posix perms. More importantly, I'm trying to<br>
get rid of the execute bit that new files are created with/inherited.<br>
</div>
<div><br>
Answers to questions below...<br>
</div>
<div><br>
</div>
<div><br>
On Fri, 2022-09-02 at 09:23 +0100, Jonathan Buzzard wrote:<br>
> On 01/09/2022 22:18, Taylor Joshua George (PSI) wrote:<br>
> <br>
> > <br>
> > Hi Everyone,<br>
> > I'm trying implement some ACLs, however some of the documentation<br>
> > is a<br>
> > bit unclear to me.<br>
> > <br>
> > Using<br>
> ><br>
> <a href="https://www.ibm.com/docs/en/spectrum-scale/5.1.4?topic=administration-setting-nfs-v4-access-control-lists" rel="noreferrer" target="_blank">
https://www.ibm.com/docs/en/spectrum-scale/5.1.4?topic=administration-setting-nfs-v4-access-control-lists</a><br>
> > as a reference, I'm trying to understand what to use to achieve<br>
> > 0660<br>
> > permissions on files and 2770 on directories.<br>
> > <br>
> <br>
> It's not clear from this whether you are trying to achieve the <br>
> equivalent of 0660 and 2770 on files and directories or have an ls<br>
> show <br>
> the permissions as 0660 and 2770.<br>
</div>
<div><br>
I'm trying to get the files to be created with 0660 perms (currently,<br>
they are created 0770). I've tried playing with the `rwxc` in the first<br>
line of the NFS4 ACL definition, with no luck (it seems to ignore that,<br>
except for error checking). E.g. I've tried removing the `x`, which<br>
passes the syntax check but doesn't seem to change anything.<br>
</div>
<div><br>
so, daemon uses ACLs to write/create files, users use posix perms to<br>
access/modify those files.<br>
</div>
<div><br>
> <br>
> > So far, I've managed to achieve 0000 perms, but user with the ACL<br>
> > permission can chmod, or 0770 perms.<br>
> > <br>
> <br>
> Basically neither of the above two options is possible because there<br>
> is <br>
> no exact mapping between POSIX permissions and NFSv4 ACL's.<br>
> <br>
> For example you can't get the equivalent of the set group id<br>
> permission. <br>
> You can however put an inheritable ACL for a group on the directory<br>
> that <br>
> gives r/w plus say search directory and possibly execute permissions<br>
> if <br>
> you want those as well.<br>
> <br>
> A user with ACL permissions can change permissions that is completely<br>
> expected. Note that traditional 2770 permissions are only suggestive,<br>
> the file or member of the group would be able to change them to <br>
> something else. In fact programs often do when you save, and Samba<br>
> just <br>
> completely ignores them for the most part. At least with NFSv4 ACL's<br>
> you <br>
> can remove the ACL permission :-)<br>
> <br>
> How permissions display on an ls/stat is not an exact mapping and<br>
> will <br>
> tend to go to something like 0000, but actual ability to access etc.<br>
> the <br>
> file will be based on the ACL not what you see in ls/stat.<br>
> > Attached is a txt file with the mmgetacl output, as well as file<br>
> > listing on a test file, and finally, the ACL definition I used.<br>
> > <br>
> > As one can see in the attachment, the ACL requested appears<br>
> > differently<br>
> > for what it _actually_ applied.<br>
> > <br>
> <br>
> What ACL schematics does the file system have? Is it NFSv4 or both?<br>
> <br>
</div>
<div><br>
It's pure NFSv4<br>
-D nfs4 File locking semantics in effect<br>
-k nfs4 ACL semantics in effect<br>
</div>
<div><br>
> <br>
> If you are wedded to POSIX style permissions perhaps change to POSIX<br>
> ACL <br>
> schematics on the file system?<br>
</div>
<div><br>
I confess, I was hoping to mix the perms so as not to change our<br>
processes too much. (we currently use reg. posix perms to enable group<br>
writes [via sgid])<br>
</div>
<div><br>
> <br>
> <br>
> JAB.<br>
> <br>
</div>
<div><br>
</div>
<div>_______________________________________________<br>
</div>
<div>gpfsug-discuss mailing list<br>
</div>
<div>gpfsug-discuss at gpfsug.org<br>
</div>
<div><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org">http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org</a><br>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div><span>
<pre>-- <br></pre>
<pre>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
</pre>
</span></div>
</body>
</html>