On Wed, 3 Mar 2010, David Dyer-Bennet wrote: > 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?
It's the "historical" way to do it. Best practices change over time. As I've already indicated, I would get no benefits from such a practice, and it would result in 70000 extra unnecessary groups in my environment. It used to be common practice to leave your smtp servers as open relays, would you have argued against locking them down because implementing smtp authentication was too hard for you? It used to be common practice to access servers via telnet, would you have argued against the deployment of ssh because you didn't want to learn how to configure it? Your basic premise in this argument seems to be that the tools to create a pure-ACL environment shouldn't be made available to anyone because you don't understand ACL's, they're too hard (for you) to use, and you would have to change how you do things. > 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 conversely, every time I consider a script or application for my current deployment, I have to do extensive testing to make sure it doesn't break my ACL's. It can't always be about you. > 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. The option I propose would only be configurable by someone who had privileges to update zfs filesystem properties. If that's the sysadmin, clearly he wants it that way. If end users are delegated that privilege, they must be deemed competent enough to shoot their own foot. > The command-line interface to ACLs is confusing, possibly weak. Matter of perspective. I don't have much trouble with it, and if I did I'd write my own interface (as I've done before http://www.cpan.org/modules/by-authors/id/PHENSON/aclmod-1.1.readme). > 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. Somebody has to go first or it's a chicken and egg problem. And it seems reasonable that the people who do go first will run into issues that need new best practices to be deployed, no? And then it kind of sucks that people who aren't even using the technology cry that models shouldn't change while fearfully grasping their buggy whips ;). > 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. If it's your server, you choose whether the option is used. If it's not your server, or the user has been granted permission to manage their own filesystem, then it seems it's not really up to you, and I'm not sure why you think you should be able to dictate what other people do with their own environments. > We're all arguing for what will work best for us, I think; selfish, but I > hope in the "sanely selfish" region. The difference is I'm arguing for functionality that I need and will be valuable in my environment. You're arguing that someone else shouldn't be able to get the functionality they need because you won't be happy if it exists at all, even if no one forces you to use it. It seems that's an entirely different grade of selfishness, like a bully who knocks you down and steals your lunch but just throws it away because he doesn't like peanut butter :(. It's not about getting something you need but just keeping someone else from having it. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
