On Tue, March 2, 2010 15:12, Paul B. Henson wrote: > On Tue, 2 Mar 2010, David Dyer-Bennet wrote: > >> Hmmm; the "lack of flexibility" you talk about comes from not using the >> security model sensibly -- having per-person groups is very useful in >> that security model. > > I have 70 odd thousand users. Why would I want to also have 70 thousand > groups with only one user in each one? From an authorization perspective, > the user and group are identical. The absolute only reason to implement > such a duplicative environment is so you can have one umask, but still be > able to control whether or not someone other than the user gets > permissions > on new files. In a world with inheritable ACL's, you don't need to do > that.
It's the normal way to do it; not sure where in the Linux world it arose, but I first saw it in some early distribution. It's done automatically by "adduser". In my perception, it's "best practice". So the question is, why do you NOT want to do it? >> You see it as a "legacy security model"; but for me it's the primary >> security model, with ACLs as an add-on. It's the only one that's >> supported across the various ways of sharing the disks. In the end, >> Solaris is one player in the POSIX world, and cutting yourself off from >> that would be very limiting. > > If the design requirements of your filesystem require backward > interoperability, then yes. On the other hand, if they don't, and you > would > be better served with a pure-ACL deployment, why hold yourself down with > the chains of a security model you don't need? I can't believe in that model. If I buy it, every time I consider a script set or application for use, I have to do extensive testing to verify that it works in the model. And I have to deal with users having that problem on their own. This is far, far too expensive to give any serious consideration to. This is why people hate flag-day changes. >> It's precisely to avoid having shell access being a poor stepchild that >> I'm resisting ACLs. As currently implemented, they relegate my primary >> access to the system to second-class status. > > How so? Do you mean operating in a shell on a system with no ACL support? The command-line interface to ACLs is confusing, possibly weak. >> And NFSv4 is mostly a rumor in my universe; NFSv2 and v3 are what people >> actually use. > > Really? We've deployed NFSv4 here, and other than this ACL/chmod issue > it's > working great. I think I'd rather design my future technology based on the > needs and possibilities of the future, not on the past. From that > perspective, why should Sun bother to work on NFSv4 at all if nobody uses > it. Generally you have to work on things for a while before they get widespread adoption, especially by outside implementers. It's entirely possible that NFS V4 will be widely used, but from what I read on linux sysadmin forums, it isn't yet. > Again, I'm not advocating removing any current functionality or depriving > you of anything you currently have. I'm simply requesting an additional > feature set that would be very useful for some deployments. I'm not really > sure why people keep arguing about why it would not be good for their > deployment, and considering such a reason it should not be implemented -- > that seems a bit self-centered. When a tool is there, people will want to use it. When using it causes me endless trouble, I don't want them to use it. We're all arguing for what will work best for us, I think; selfish, but I hope in the "sanely selfish" region. -- 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
