=== 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 | ||
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:16 |
---|---|---|
slangasek | um | 18:20 |
slangasek | no, acls work fine | 18:20 |
slangasek | maybe an idmap configuration error? | 18:20 |
blkperl | slangasek: if we force nfs3, it works fine.... | 18:39 |
slangasek | and how are the acls being implemented? idmapd, kerberos? | 18:40 |
blkperl | zfs acls from Solaris 11 nfs server | 18:40 |
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:41 |
blkperl | ok | 18:42 |
blkperl | well it looks "right" when I run nfs4_getacl | 18:42 |
* nibalizer hears we're arguing about nfs | 18:42 | |
blkperl | slangasek: and its only deny read, everything else is workign... | 18:45 |
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:46 |
blkperl | ok :) | 18:47 |
nathwill | uids have to be sync'd with nfsv4 | 18:48 |
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:49 |
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:51 |
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:52 |
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:53 |
blkperl | shouldn't the extended acls override the normal ones? | 18:54 |
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:55 |
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:56 |
blkperl | so bug in nfs4? | 18:57 |
blkperl | or screwness anyway | 18:57 |
slangasek | well, I'm not sure | 18:57 |
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:58 |
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 | 18:59 |
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:00 |
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:01 |
blkperl | wvan owns the directory on both client and server, and should be denied read access to the files in the wvan folder | 19:02 |
blkperl | they wanted a "write only dropbox" created | 19:03 |
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:05 |
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:06 |
blkperl | slangasek: appears to only be an issue on 12.04.... | 19:07 |
blkperl | works fine on 14.04 | 19:07 |
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? | 19:08 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!