=== shirgall is now known as 17WAA0FN4 === hitchcock.freenode.net changed the topic of #ubuntu-us-or to: ★Welcome to the Ubuntu Oregon Local Community Team!★ | ► Webpage: http://ubuntu-oregon.org | ► IRC Meeting: None Scheduled | ► Events: 3/3/13 Global Jam @ FreeGeek | ► Contribute to Ubuntu - http://j.mp/LskTNG | 13.04 is now release \o/ === shirgall is now known as Guest8372 === Guest8372 is now known as shirgall === shirgall is now known as Guest76513 === Odysimus is now known as Guest67678 === Brian_H_ is now known as Brian_H === Odysimus is now known as Guest38001 [18:16] 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] um [18:20] no, acls work fine [18:20] maybe an idmap configuration error? [18:39] slangasek: if we force nfs3, it works fine.... [18:40] and how are the acls being implemented? idmapd, kerberos? [18:40] zfs acls from Solaris 11 nfs server [18:41] "zfs acls" EPARSE; the question is how they're represented in NFS [18:41] which is up to the Solaris NFS server to map from ZFS to NFS, and should be black box to the client [18:42] ok [18:42] well it looks "right" when I run nfs4_getacl [18:42] * nibalizer hears we're arguing about nfs [18:45] slangasek: and its only deny read, everything else is workign... [18:46] 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] ok :) [18:48] uids have to be sync'd with nfsv4 [18:49] if the uid/guid's are different, it will suuuuuck [18:49] they are the same, via ldap [18:49] no, that's what idmap is for [18:49] http://i.imgur.com/3sFfTQL.gif [18:51] slangasek: https://gist.github.com/blkperl/8789892 [18:51] we've just generally taken to setting uids/guids in the user databag in chef, which works ok. [18:51] slangasek: first one is for directories, second one is for files [18:52] blkperl: er, I don't see getfacl output there [18:52] its the top thing [18:52] no [18:52] not nfs4_getfacl [18:52] getfacl [18:52] oh [18:53] added [18:53] yeah getfacl shows a different story [18:53] oh [18:53] lololol [18:53] so basicalyl we had the extended acls set right but the normal acls wrong? [18:53] that amuses me [18:54] shouldn't the extended acls override the normal ones? [18:55] it returns the same thing on nfs3 though [18:55] hmm, really? [18:55] yep [18:55] so getfacl is lying [18:55] no, getfacl is telling the truth [18:55] :) [18:55] why? [18:56] all getfacl does is ask the kernel for the POSIX acl on the file [18:56] so it's always "correct" [18:56] if there's something screwy about how the kernel interprets the mix of posix acls and nfs4 acls, well... [18:57] so bug in nfs4? [18:57] or screwness anyway [18:57] well, I'm not sure [18:58] 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] OOI, if you mount with -oacl, does that make a difference? [18:59] nfs(5): acl / noacl Selects whether to use the NFSACL sideband protocol on [18:59] this mount point. The NFSACL sideband protocol is a [18:59] proprietary protocol implemented in Solaris that manages [18:59] Access Control Lists. NFSACL was never made a standard [18:59] part of the NFS protocol specification. [18:59] slangasek: nope, -o acl does nothing [19:00] "does nothing" as in, you still get write access where you shouldn't? [19:00] still read access, where I shouldn't [19:00] ok [19:01] 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] wvan owns the directory on both client and server, and should be denied read access to the files in the wvan folder [19:03] they wanted a "write only dropbox" created [19:05] ah, denying a user read access to their own files could be a corner case [19:05] :) [19:05] I'd suggest verifying whether the problem is reproducible with a simpler acl requirement... like perms for a non-owning user [19:05] yeah it works for non-owning user [19:06] but that could be the posix or extended acls enforcing that... [19:06] oh, well, then I guess you've got a kernel bug for the owning-user case [19:06] how exciting.... [19:06] you could verify by adding an acl for a single additional user [19:07] slangasek: appears to only be an issue on 12.04.... [19:07] works fine on 14.04 [19:08] ah, well then [19:08] what about giving a different user owner on the parent dircetory [19:08] then -x for the user on that directory [19:08] can you still write a file if you have +w but not -x? === adam_g` is now known as adam_g === nibalizer is now known as mostawesomedude === mostawesomedude is now known as nibalizer === shirgall is now known as Guest34486