On Mon, March 1, 2010 15:50, Miles Nordin wrote: >>>>>> "dd" == David Dyer-Bennet <d...@dd-b.net> writes: > > dd> Okay, but the argument goes the other way just as well -- when > dd> I run "chmod 6400 foobar", I want the permissions set that > dd> specific way, and I don't want some magic background feature > dd> blocking me. > > This will be true either way. Even if chmod isn't ignored, it will > reach into the nest of ACL's and mangle them in some non-obvious way > with unpredictable consequences, and the mangling will be implemented > by a magical background feature. AIUI if you really want the ACL's > cleared and thus the ACL-ignorant intent of your chmod implemented, > you have to use a bunch of ACL-specific commands and pay attention to > inheritance as well. What you're asking is that something happen when > you do the chmod, but you don't care WHAT happens so long as it's > SOMETHING. This is really dumb.
That's getting pretty nasty. If I sit and think, "I want read-write access for the owner, and read-only access for people in the file's group, and no access for anybody else", the natural thing to do is type "chmod 640 foobar" (sorry about the original typo in the mode value!). And I'm not arguing for any particular outcome; I'm arguing that all outcomes mentioned so far, and quite possibly all possible outcomes, will be surprising and nasty from some significant point of view. And I'm trying to argue against privileging ACLs over mode values. > dd> Particulary if "I" am a complex system of scripts that wasn't > dd> even written locally. > > Yeah no I really think you're on the wrong side of this one! > > We must stop imagining we're running on a Unix filesystem. Once > you've added ACL's you're basically running on an NTFS and should not > expect chmod to work any more than we expect it to do anything sane > through ntfs-3g. The only reasonable goals are ``least surprise'' and > ``maintainability''. So we're trying to bury a massive flag-day change, no forwards or backwards compatibility, under the fairly innocent heading "ACLs", eh? Well, that's one approach. And it may be the best approach in some ways. However, I gotta say that things worked better with SAMBA, and that specifically the ACLS has made converting to using CIFS a total nightmare. If I'd understood in advance I wouldn't have done it. > Implementing Unix permissions as a special subcase of NFSv4 ACL's is > good because it probably lets Windows clients make sense of the Unix > permissions better than Samba did? but it's a mistake to focus on > this one difficult case while disregarding the experiences of other > legacy clients, like for example on Linux if I mount something with > NFS **v3**, I get a bunch of + signs from GNU ls warning me there are > mysteryACL's (POSIX ones! more magical backgroudn translation!) > attached to every single file even though there aren't, and this > breaks a couple obscure scripts, like genkernel IIRC. The more > important downside though might be that it's led to a lot of fuzzy > compromises in the way people think about the whole disaster, and > probably will forever as long as new people keep showing up to the > party: much of the value of our legacy was pissed away through this > hubris. Yeah, I think that's kinda what I'm objecting to. -- David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
