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