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.
Hi!
> Am 20.08.2019 um 20:35 schrieb Goetz, Patrick G <[email protected]>:
>
> 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
http://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
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.
>
>
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 <[email protected]>:
>>
>> 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
>
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. <<
>