[18:16] <blkperl> slangasek: are NFSv4 acls broken on Ubuntu? Our Solaris and RedHat clients are properly denying read access to files, but Ubuntu isn't.....
[18:20] <slangasek> um
[18:20] <slangasek> no, acls work fine
[18:20] <slangasek> maybe an idmap configuration error?
[18:39] <blkperl> slangasek: if we force nfs3, it works fine....
[18:40] <slangasek> and how are the acls being implemented?  idmapd, kerberos?
[18:40] <blkperl> zfs acls from Solaris 11 nfs server
[18:41] <slangasek> "zfs acls" EPARSE; the question is how they're represented in NFS
[18:41] <slangasek> which is up to the Solaris NFS server to map from ZFS to NFS, and should be black box to the client
[18:42] <blkperl> ok
[18:42] <blkperl> well it looks "right" when I run nfs4_getacl
[18:42]  * nibalizer hears we're arguing about nfs
[18:45] <blkperl> slangasek: and its only deny read, everything else is workign...
[18:46] <slangasek> blkperl: can you show me an example acl, and the corresponding output of getfacl for the file in question when run on the Ubuntu client?
[18:47] <blkperl> ok :)
[18:48] <nathwill> uids have to be sync'd with nfsv4
[18:49] <nathwill> if the uid/guid's are different, it will suuuuuck
[18:49] <blkperl> they are the same, via ldap
[18:49] <slangasek> no, that's what idmap is for
[18:49] <nathwill> http://i.imgur.com/3sFfTQL.gif
[18:51] <blkperl> slangasek: https://gist.github.com/blkperl/8789892
[18:51] <nathwill> we've just generally taken to setting uids/guids in the user databag in chef, which works ok.
[18:51] <blkperl> slangasek: first one is for directories, second one is for files
[18:52] <slangasek> blkperl: er, I don't see getfacl output there
[18:52] <blkperl> its the top thing
[18:52] <slangasek> no
[18:52] <slangasek> not nfs4_getfacl
[18:52] <slangasek> getfacl
[18:52] <blkperl> oh
[18:53] <blkperl> added
[18:53] <blkperl> yeah getfacl shows a different story
[18:53] <nibalizer> oh
[18:53] <nibalizer> lololol
[18:53] <nibalizer> so basicalyl we had the extended acls set right but the normal acls wrong?
[18:53] <nibalizer> that amuses me
[18:54] <blkperl> shouldn't the extended acls override the normal ones?
[18:55] <blkperl> it returns the same thing on nfs3 though
[18:55] <slangasek> hmm, really?
[18:55] <blkperl> yep
[18:55] <blkperl> so getfacl is lying
[18:55] <slangasek> no, getfacl is telling the truth
[18:55] <slangasek> :)
[18:55] <blkperl> why?
[18:56] <slangasek> all getfacl does is ask the kernel for the POSIX acl on the file
[18:56] <slangasek> so it's always "correct"
[18:56] <slangasek> if there's something screwy about how the kernel interprets the mix of posix acls and nfs4 acls, well...
[18:57] <blkperl> so bug in nfs4?
[18:57] <blkperl> or screwness anyway
[18:57] <slangasek> well, I'm not sure
[18:58] <slangasek> really, the way the acls are *meant* to be handled is that the client should tell the server which user credentials are being used for access, and the server should block if it doesn't match the acl
[18:58] <slangasek> OOI, if you mount with -oacl, does that make a difference?
[18:59] <slangasek> nfs(5):        acl / noacl    Selects whether to use the NFSACL sideband  protocol  on
[18:59] <slangasek>                       this  mount  point.   The  NFSACL sideband protocol is a
[18:59] <slangasek>                       proprietary protocol implemented in Solaris that manages
[18:59] <slangasek>                       Access  Control  Lists. NFSACL was never made a standard
[18:59] <slangasek>                       part of the NFS protocol specification.
[18:59] <blkperl> slangasek: nope, -o acl does nothing
[19:00] <slangasek> "does nothing" as in, you still get write access where you shouldn't?
[19:00] <blkperl> still read access, where I shouldn't
[19:00] <slangasek> ok
[19:01] <slangasek> wvan is the owning user of the example directory, on both client and server?  and you're testing access as another (non-root) user?
[19:02] <blkperl> wvan owns the directory on both client and server, and should be denied read access to the files in the wvan folder
[19:03] <blkperl> they wanted a "write only dropbox" created
[19:05] <slangasek> ah, denying a user read access to their own files could be a corner case
[19:05] <blkperl> :)
[19:05] <slangasek> I'd suggest verifying whether the problem is reproducible with a simpler acl requirement... like perms for a non-owning user
[19:05] <blkperl> yeah it works for non-owning user
[19:06] <blkperl> but that could be the posix or extended acls enforcing that...
[19:06] <slangasek> oh, well, then I guess you've got a kernel bug for the owning-user case
[19:06] <blkperl> how exciting....
[19:06] <slangasek> you could verify by adding an acl for a single additional user
[19:07] <blkperl> slangasek: appears to only be an issue on 12.04....
[19:07] <blkperl> works fine on 14.04
[19:08] <slangasek> ah, well then
[19:08] <nibalizer> what about giving a different user owner on the parent dircetory
[19:08] <nibalizer> then -x for the user on that directory
[19:08] <nibalizer> can you still write a file if you have +w but not -x?