/srv/irclogs.ubuntu.com/2014/02/03/#ubuntu-us-or.txt

=== 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
blkperlslangasek: are NFSv4 acls broken on Ubuntu? Our Solaris and RedHat clients are properly denying read access to files, but Ubuntu isn't.....18:16
slangasekum18:20
slangasekno, acls work fine18:20
slangasekmaybe an idmap configuration error?18:20
blkperlslangasek: if we force nfs3, it works fine....18:39
slangasekand how are the acls being implemented?  idmapd, kerberos?18:40
blkperlzfs acls from Solaris 11 nfs server18:40
slangasek"zfs acls" EPARSE; the question is how they're represented in NFS18:41
slangasekwhich is up to the Solaris NFS server to map from ZFS to NFS, and should be black box to the client18:41
blkperlok18:42
blkperlwell it looks "right" when I run nfs4_getacl18:42
* nibalizer hears we're arguing about nfs18:42
blkperlslangasek: and its only deny read, everything else is workign...18:45
slangasekblkperl: 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
blkperlok :)18:47
nathwilluids have to be sync'd with nfsv418:48
nathwillif the uid/guid's are different, it will suuuuuck18:49
blkperlthey are the same, via ldap18:49
slangasekno, that's what idmap is for18:49
nathwillhttp://i.imgur.com/3sFfTQL.gif18:49
blkperlslangasek: https://gist.github.com/blkperl/878989218:51
nathwillwe've just generally taken to setting uids/guids in the user databag in chef, which works ok.18:51
blkperlslangasek: first one is for directories, second one is for files18:51
slangasekblkperl: er, I don't see getfacl output there18:52
blkperlits the top thing18:52
slangasekno18:52
slangaseknot nfs4_getfacl18:52
slangasekgetfacl18:52
blkperloh18:52
blkperladded18:53
blkperlyeah getfacl shows a different story18:53
nibalizeroh18:53
nibalizerlololol18:53
nibalizerso basicalyl we had the extended acls set right but the normal acls wrong?18:53
nibalizerthat amuses me18:53
blkperlshouldn't the extended acls override the normal ones?18:54
blkperlit returns the same thing on nfs3 though18:55
slangasekhmm, really?18:55
blkperlyep18:55
blkperlso getfacl is lying18:55
slangasekno, getfacl is telling the truth18:55
slangasek:)18:55
blkperlwhy?18:55
slangasekall getfacl does is ask the kernel for the POSIX acl on the file18:56
slangasekso it's always "correct"18:56
slangasekif there's something screwy about how the kernel interprets the mix of posix acls and nfs4 acls, well...18:56
blkperlso bug in nfs4?18:57
blkperlor screwness anyway18:57
slangasekwell, I'm not sure18:57
slangasekreally, 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 acl18:58
slangasekOOI, if you mount with -oacl, does that make a difference?18:58
slangaseknfs(5):        acl / noacl    Selects whether to use the NFSACL sideband  protocol  on18:59
slangasek                      this  mount  point.   The  NFSACL sideband protocol is a18:59
slangasek                      proprietary protocol implemented in Solaris that manages18:59
slangasek                      Access  Control  Lists. NFSACL was never made a standard18:59
slangasek                      part of the NFS protocol specification.18:59
blkperlslangasek: nope, -o acl does nothing18:59
slangasek"does nothing" as in, you still get write access where you shouldn't?19:00
blkperlstill read access, where I shouldn't19:00
slangasekok19:00
slangasekwvan 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
blkperlwvan owns the directory on both client and server, and should be denied read access to the files in the wvan folder19:02
blkperlthey wanted a "write only dropbox" created19:03
slangasekah, denying a user read access to their own files could be a corner case19:05
blkperl:)19:05
slangasekI'd suggest verifying whether the problem is reproducible with a simpler acl requirement... like perms for a non-owning user19:05
blkperlyeah it works for non-owning user19:05
blkperlbut that could be the posix or extended acls enforcing that...19:06
slangasekoh, well, then I guess you've got a kernel bug for the owning-user case19:06
blkperlhow exciting....19:06
slangasekyou could verify by adding an acl for a single additional user19:06
blkperlslangasek: appears to only be an issue on 12.04....19:07
blkperlworks fine on 14.0419:07
slangasekah, well then19:08
nibalizerwhat about giving a different user owner on the parent dircetory19:08
nibalizerthen -x for the user on that directory19:08
nibalizercan 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!