Re: Does NFSv4 translate POSIX ACL's?

["Goetz, Patrick G" <pgoetz@math.utexas.edu>]

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.                        <<
>