# [OmniOS-discuss] nfsv4 acls wtf moment

Natxo Asenjo natxo.asenjo at gmail.com
Sun May 12 04:00:49 EDT 2013

- Previous message: [OmniOS-discuss] nfsv4 acls wtf moment
- Next message: [OmniOS-discuss] nfsv4 acls wtf moment
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Sat, May 11, 2013 at 10:35 PM, Paul B. Henson <henson at acm.org> wrote:

    > 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.
    >
    >
    ok, thanks for your explanation. I had indeed seen all those 0664 that
    pointed in that direction.

    I see the illumos nfs 4.1 project is a bti 'inactive' ;-), but it'll come
    one day I guess.

    > 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.
    >
    >
    no, it does when moving a file though :

    $ mv testmove /net/zfstank.ipa.asenjo.nx/tank/testshare/
    mv: preserving permissions for
    `/net/zfstank.ipa.asenjo.nx/tank/testshare/testmove': Operation not
    permitted

    but that is not really a showstopper. The file gets copied and the
    permissions are applied:

    $ nfs4_getfacl /net/zfstank.ipa.asenjo.nx/tank/testshare/testmove
    A::EVERYONE@:rwadxtTnNcCoy

    I had not noticed it until yesterday because I am used to copying first and
    removing later (lost some files once because of a hardware failure and got
    used to doing that since then).

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

    I'm surprised that not more people are using this! Thanks for implementing
    it.

    --
    groet,
    natxo
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20130512/b7c23fde/attachment.html>

- Previous message: [OmniOS-discuss] nfsv4 acls wtf moment
- Next message: [OmniOS-discuss] nfsv4 acls wtf moment
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list