Does NFSv4 translate POSIX ACL's?

Does NFSv4 translate POSIX ACL's?

[Goetz, Patrick G]

Posting to this list out of desperation, as I've exhausted all the other 
resources I can get my hands on.

The full blown issue has been posted here:

 
https://unix.stackexchange.com/questions/536300/why-is-nfsv4-not-translating-posix-acls-in-a-usable-way

I have an NFSv4 exported folder (base filesystem: XFS) which must afford 
read access to a program on folders which are otherwise hidden from the 
public.  On the NFS server:

   root@kraken:/EM/EMtifs# getfacl pgoetz
   # file: pgoetz
   # owner: pgoetz
   # group: cns-cnsitlabusers
   user::rwx
   group::r-x
   other::---
   default:user::rwx
   default:user:cryosparc_user:r-x
   default:group::r-x
   default:mask::r-x
   default:other::---

   root@kraken:/EM/EMtifs# id cryosparc_user
   uid=1017(cryosparc_user) gid=1017(cryosparc_user) 
groups=1017(cryosparc_user)


The NFS client appears to be translating the POSIX ACL:

   root@javelina:/EM/EMtifs# nfs4_getfacl pgoetz
   A::OWNER@:rwaDxtTcCy
   A::GROUP@:rxtcy
   A::EVERYONE@:tcy
   A:fdi:OWNER@:rwaDxtTcCy
   A:fdi:1017:rxtcy
   A:fdi:GROUP@:rxtcy
   A:fdi:EVERYONE@:tcy

   root@javelina:/EM/EMtifs# id cryosparc_user
   uid=1017(cryosparc_user) gid=1017(cryosparc_user) 
groups=1017(cryosparc_user)

However,

   cryosparc_user@javelina:/EM/EMtifs$ whoami
   cryosparc_user
   cryosparc_user@javelina:/EM/EMtifs$ ls pgoetz
   ls: cannot open directory 'pgoetz': Permission denied

Host OS on both machines: Ubuntu 18.04
NFS version: 1.3.4
Mount entry in /etc/fstab:
   kraken.biosci.utexas.edu:/EM  /EM  nfs4  _netdev,auto  0  0


I found this document that Bruce wrote:

   https://tools.ietf.org/html/draft-ietf-nfsv4-acl-mapping-02

but it doesn't appear to have risen to the level of RFC?  RFC 7530 
doesn't appear to have anything to say on the matter.  Since the 
processing program primarily runs on the workstations, I need to make 
this work somehow, and can't add the program user to the user group as 
explained in the StackExchange post.

Re: Does NFSv4 translate POSIX ACL's?

[Daniel Kobras]

Hi!

> Am 20.08.2019 um 20:35 schrieb Goetz, Patrick G <pgoetz@math.utexas.edu>:
> 
> I have an NFSv4 exported folder (base filesystem: XFS) which must afford 
> read access to a program on folders which are otherwise hidden from the 
> public.  On the NFS server:
> 
>   root@kraken:/EM/EMtifs# getfacl pgoetz
>   # file: pgoetz
>   # owner: pgoetz
>   # group: cns-cnsitlabusers
>   user::rwx
>   group::r-x
>   other::---
>   default:user::rwx
>   default:user:cryosparc_user:r-x
>   default:group::r-x
>   default:mask::r-x
>   default:other::---

There’s only a default ACL (which is inherited to new objects), but no proper ACL on the directory itself. Have you tried

  setfacl -m u:cryosparc_user:rx

already?

Kind regards,

Daniel
-- 
Daniel Kobras
Principal Architect
Puzzle ITC Deutschland
+49 7071 14316 0
www.puzzle-itc.de







-- 
Puzzle ITC Deutschland GmbH
Sitz der Gesellschaft: Jurastr. 27/1, 72072 
Tübingen

Eingetragen am Amtsgericht Stuttgart HRB 765802
Geschäftsführer: 
Lukas Kallies, Daniel Kobras, Mark Pröhl

Re: Does NFSv4 translate POSIX ACL's?

[J. Bruce Fields]

On Tue, Aug 20, 2019 at 06:35:16PM +0000, Goetz, Patrick G wrote:
> Posting to this list out of desperation, as I've exhausted all the other 
> resources I can get my hands on.

I'm not sure I understand the setup exactly, but it doesn't appear to
have anything to do with ACLs exactly, it's users that are the problem.
You'd have exactly the same problem if you were using only mode bits.

All NFS permissions are evaluated pretty much only on the server side.
When you read a directory, for example, the client doesn't fetch the ACL
and mode bits and check permissions itself.  It just sends the READDIR
(or an ACCESS call) with rpc credentials identifying the user performing
the call, and it's up to the server whether or not to return a
permission error.

Groups are handled differently depending on the security flavor--if
you're using kerberos, it's up to the server to decide which group your
user is a member of.  If you're using auth_sys/auth_unix, then the
client sends a list of groups with each rpc call.  (But the Linux server
has a --manage-gids option that tells the server to ignore that and use
server side group memberships.)

Hope that helps.  This doesn't look like anything to do with ACL
mapping, in any case.

--b.


> The full blown issue has been posted here:
> 
>  
> https://unix.stackexchange.com/questions/536300/why-is-nfsv4-not-translating-posix-acls-in-a-usable-way
> 
> I have an NFSv4 exported folder (base filesystem: XFS) which must afford 
> read access to a program on folders which are otherwise hidden from the 
> public.  On the NFS server:
> 
>    root@kraken:/EM/EMtifs# getfacl pgoetz
>    # file: pgoetz
>    # owner: pgoetz
>    # group: cns-cnsitlabusers
>    user::rwx
>    group::r-x
>    other::---
>    default:user::rwx
>    default:user:cryosparc_user:r-x
>    default:group::r-x
>    default:mask::r-x
>    default:other::---
> 
>    root@kraken:/EM/EMtifs# id cryosparc_user
>    uid=1017(cryosparc_user) gid=1017(cryosparc_user) 
> groups=1017(cryosparc_user)
> 
> 
> The NFS client appears to be translating the POSIX ACL:
> 
>    root@javelina:/EM/EMtifs# nfs4_getfacl pgoetz
>    A::OWNER@:rwaDxtTcCy
>    A::GROUP@:rxtcy
>    A::EVERYONE@:tcy
>    A:fdi:OWNER@:rwaDxtTcCy
>    A:fdi:1017:rxtcy
>    A:fdi:GROUP@:rxtcy
>    A:fdi:EVERYONE@:tcy
> 
>    root@javelina:/EM/EMtifs# id cryosparc_user
>    uid=1017(cryosparc_user) gid=1017(cryosparc_user) 
> groups=1017(cryosparc_user)
> 
> However,
> 
>    cryosparc_user@javelina:/EM/EMtifs$ whoami
>    cryosparc_user
>    cryosparc_user@javelina:/EM/EMtifs$ ls pgoetz
>    ls: cannot open directory 'pgoetz': Permission denied
> 
> Host OS on both machines: Ubuntu 18.04
> NFS version: 1.3.4
> Mount entry in /etc/fstab:
>    kraken.biosci.utexas.edu:/EM  /EM  nfs4  _netdev,auto  0  0
> 
> 
> I found this document that Bruce wrote:
> 
>    https://tools.ietf.org/html/draft-ietf-nfsv4-acl-mapping-02
> 
> but it doesn't appear to have risen to the level of RFC?  RFC 7530 
> doesn't appear to have anything to say on the matter.  Since the 
> processing program primarily runs on the workstations, I need to make 
> this work somehow, and can't add the program user to the user group as 
> explained in the StackExchange post.
> 
> 

Re: Does NFSv4 translate POSIX ACL's?

[Goetz, Patrick G]

Hi Daniel -

Thanks so much for your help!  That was indeed the problem.  I didn't 
realize that default ACL's don't count as actionable ACL's (other than 
to dictate authorization for new sub-directories and files).


On 8/20/19 2:14 PM, Daniel Kobras wrote:
> Hi!
> 
>> Am 20.08.2019 um 20:35 schrieb Goetz, Patrick G <pgoetz@math.utexas.edu>:
>>
>> I have an NFSv4 exported folder (base filesystem: XFS) which must afford
>> read access to a program on folders which are otherwise hidden from the
>> public.  On the NFS server:
>>
>>    root@kraken:/EM/EMtifs# getfacl pgoetz
>>    # file: pgoetz
>>    # owner: pgoetz
>>    # group: cns-cnsitlabusers
>>    user::rwx
>>    group::r-x
>>    other::---
>>    default:user::rwx
>>    default:user:cryosparc_user:r-x
>>    default:group::r-x
>>    default:mask::r-x
>>    default:other::---
> 
> There’s only a default ACL (which is inherited to new objects), but no proper ACL on the directory itself. Have you tried
> 
>    setfacl -m u:cryosparc_user:rx
> 
> already?
> 
> Kind regards,
> 
> Daniel
> 

Re: Does NFSv4 translate POSIX ACL's?

[Goetz, Patrick G]

Hi -

Yes, this, along with Daniel's comment, was enormously helpful in 
allowing me to figure out what was going wrong.  Thank you!


On 8/20/19 2:15 PM, J. Bruce Fields wrote:
> On Tue, Aug 20, 2019 at 06:35:16PM +0000, Goetz, Patrick G wrote:
>> Posting to this list out of desperation, as I've exhausted all the other
>> resources I can get my hands on.
> 
> I'm not sure I understand the setup exactly, but it doesn't appear to
> have anything to do with ACLs exactly, it's users that are the problem.
> You'd have exactly the same problem if you were using only mode bits.
> 
> All NFS permissions are evaluated pretty much only on the server side.
> When you read a directory, for example, the client doesn't fetch the ACL
> and mode bits and check permissions itself.  It just sends the READDIR
> (or an ACCESS call) with rpc credentials identifying the user performing
> the call, and it's up to the server whether or not to return a
> permission error.
> 
> Groups are handled differently depending on the security flavor--if
> you're using kerberos, it's up to the server to decide which group your
> user is a member of.  If you're using auth_sys/auth_unix, then the
> client sends a list of groups with each rpc call.  (But the Linux server
> has a --manage-gids option that tells the server to ignore that and use
> server side group memberships.)
> 
> Hope that helps.  This doesn't look like anything to do with ACL
> mapping, in any case.
> 
> --b.
> 
> 
>> The full blown issue has been posted here:
>>
>>   
>> https://unix.stackexchange.com/questions/536300/why-is-nfsv4-not-translating-posix-acls-in-a-usable-way
>>
>> I have an NFSv4 exported folder (base filesystem: XFS) which must afford
>> read access to a program on folders which are otherwise hidden from the
>> public.  On the NFS server:
>>
>>     root@kraken:/EM/EMtifs# getfacl pgoetz
>>     # file: pgoetz
>>     # owner: pgoetz
>>     # group: cns-cnsitlabusers
>>     user::rwx
>>     group::r-x
>>     other::---
>>     default:user::rwx
>>     default:user:cryosparc_user:r-x
>>     default:group::r-x
>>     default:mask::r-x
>>     default:other::---
>>
>>     root@kraken:/EM/EMtifs# id cryosparc_user
>>     uid=1017(cryosparc_user) gid=1017(cryosparc_user)
>> groups=1017(cryosparc_user)
>>
>>
>> The NFS client appears to be translating the POSIX ACL:
>>
>>     root@javelina:/EM/EMtifs# nfs4_getfacl pgoetz
>>     A::OWNER@:rwaDxtTcCy
>>     A::GROUP@:rxtcy
>>     A::EVERYONE@:tcy
>>     A:fdi:OWNER@:rwaDxtTcCy
>>     A:fdi:1017:rxtcy
>>     A:fdi:GROUP@:rxtcy
>>     A:fdi:EVERYONE@:tcy
>>
>>     root@javelina:/EM/EMtifs# id cryosparc_user
>>     uid=1017(cryosparc_user) gid=1017(cryosparc_user)
>> groups=1017(cryosparc_user)
>>
>> However,
>>
>>     cryosparc_user@javelina:/EM/EMtifs$ whoami
>>     cryosparc_user
>>     cryosparc_user@javelina:/EM/EMtifs$ ls pgoetz
>>     ls: cannot open directory 'pgoetz': Permission denied
>>
>> Host OS on both machines: Ubuntu 18.04
>> NFS version: 1.3.4
>> Mount entry in /etc/fstab:
>>     kraken.biosci.utexas.edu:/EM  /EM  nfs4  _netdev,auto  0  0
>>
>>
>> I found this document that Bruce wrote:
>>
>>     https://tools.ietf.org/html/draft-ietf-nfsv4-acl-mapping-02
>>
>> but it doesn't appear to have risen to the level of RFC?  RFC 7530
>> doesn't appear to have anything to say on the matter.  Since the
>> processing program primarily runs on the workstations, I need to make
>> this work somehow, and can't add the program user to the user group as
>> explained in the StackExchange post.
>>
>>
>>> This message is from an external sender. Learn more about why this <<
>>> matters at https://links.utexas.edu/rtyclf.                        <<
>