[OmniOS-discuss] nfsv4 acls wtf moment

Paul B. Henson henson at acm.org
Sat May 11 16:35:13 EDT 2013


On Sat, May 11, 2013 at 09:12:43AM +0200, Natxo Asenjo wrote:

> I have straced the cp -r command with discard and restricted aclmode
> settings (see attachments).

open("/net/zfstank.ipa.asenjo.nx/tank/testshare/bin/parsetable.pl",
O_WRONLY|O_CREAT|O_EXCL, 0664) = 4

Yeah, you're getting bit by the NFS exclusive open issue. Basically, NFS
up to v4 overloads the mode bits to store a verifier to check on whether
the exclusive part of the open succeeded, and then does a separate
setattr afterwards to set the actual mode. So what happens is the
initial open results in a file with the right inherited ACL, and the
subsequent setattr results in the same change as an explicit chmod,
typically breaking the ACL. This is fixed in the NFS v4.1 spec, but
that's not really in use yet. Theoretically it should be possible to
keep some state on the server side and work around this issue, but I've
never had the time to dig into it.

Does the linux nfs client complain at all when you do the copy with
aclmode=restricted? The client would get a success for the open, but the
following setattr op would fail, and I wasn't sure how the nfs client
would deal with that. From the strace output it looks like the
underlying nfs setattr failure isn't passed back up to the userland
code, it looks like the open just succeeds as normal. Cool.


I'm glad somebody's finding aclmode=restricted useful :).


More information about the OmniOS-discuss mailing list