| gabriel rosenkoetter on Mon, 3 Feb 2003 15:54:16 -0500 |
|
On Mon, Feb 03, 2003 at 10:47:03AM -0500, Brian Epstein wrote: > Well, we'll have to agree to disagree, then. ACLs don't work the same > across OSs, or across filesystems. That feels like FUD. Do you have a specific circumstance in which you had trouble? Do you just mean that the user interface is different? (That may be true now, but it should be going away as OSes come into compliance with the standards.) Everything I've personally interacted with follows the POSIX (or is this a SUS standard? never recall) standard enough to interoperate (which is kind of the point of POSIX and SUS). Certainly, just using AFS everywhere is possible and will get the job done. Unless you've got files larger than 2 GB, in which case you can't use AFS. :^> > And in general, most SAs wouldn't know a filesystem ACL if they > tripped over one. That's either an outrageous statement or an outrageous state of being if it's actually true. That's like saying, "Most physicians are totally unaware of bone marrow transplants." You can't really take part in a profession if you aren't keeping up with the times. > They are not obvious in most situations like file permissions. Yes they are. There's a specific, standardized way to show the existence of an ACL in a long ls(1) listing: a + after the normal permission bits. > I don't understand why you think at any point User Private Groups > suggests adding one user to anothers Private Group. This is not how the > scheme was intended to be used. If Bob has a private group, it should > stay private. If Alice wants to share files with Bob, she shouldn't be > added to his private group. > > And Bob should not be added to Alice's. A new group should be created > and Bob and Alice should be added to that new group. Then why do I need to waste a group each for Alice and Bob? They should both be in users, and have done with it. > Yes, this is the whole point, and by using User Private Groups, this > does not reduce the security of the home directory. It does, however, break the traditional presumptions of a lot of otherwise portable software. Like OpenSSH. (Which, if memory serves, was what started this whole argument.) [clip near exact quote of documentation] I really do understand what Red Hat and you are saying, and it's a little offensive that you chose to quote back to me exactly what I had obviously just read and was responding to. And I still say it has NOTHING to do with giving each user their own private group, and everything to do with beating them over the head with a default umask they should be educated to understand rather than led blindly into using. Even if you're going to do that, there's no reason for the users' *default* umask to be 002, that umask is only necessary within the project directory. So make yourself an infrastructure in /etc/profile (or wherever you want so that it gets loaded into all login shells... Red Hat's /etc/profile.d would be an ideal place for umask.sh and umask.csh files) to process a .umask file upon entering a directory. Make sure you avoid touching known globally shared spaces (/tmp, /var/tmp). Then you're not wasting groups and not having users running around creating a bunch of files with scary permissions in places other than project directories (unless they actively set the umask, in which case they presumably know what they're doing, and could easily remove your .umask configuration from their shells if the wanted to). Surely echo 002 > .umask isn't too much trouble when you're already doing chmod 2775 . > > cooperative web development, then it's far more reasonable that > > there be a group web of which they are both members. > This is exactly how User Private Groups work. No, that has absolutely nothing to do with user private groups. It's got to do with a umask setting and a very much NOT private group. > Not if you open your mind to a new way of thinking. It is not insecure > if they are the only member of the group. The umask is not insecure, it > gives no users more permissions unless you are in a directory with the > SetGID bit set. These directories are used for group collaboration, and > should be setup by root anyway. Yes, the umask, as a default, is insecure, because if a user performs a su -m or a newgrp(1), they'll retain the umask, but change the group ID, which means they'll make files which, because they're trusting in the system, they'll presume are secure when, in fact, they may be writable by another party. > Yeah, right. How many users have you been able to educate without the > use of a LART? Plenty. umask is a simple concept. It's easier to explain than ACLs, which I've also done without much trouble. > Personally, I've tried both methods. Believe me, SAs have enough > headaches. Using User Private Groups adds benefit, it does not reduce > security. It is a different way of thinking. Yes, it does reduce security. Yes, it's a different way of thinking. Unfortunately, it's also a different way of thinking than that of most application vendors, which means that it'll break interactions between those applications and the operating system. OpenSSH is the star example here. > Trust me, I was just as skeptical when I first came upon UPGs. After > doing some research and trying it in a production environment, I found > that the number of calls to re-permission directories and help users > with confusing chmod commands drastically reduced. I've already solved that problem with group ownership of directories with sgid bits set where necessary (note that SysV is what requires the sgid bit set; BSD presumes you mean to create a file with the ownership of the parent directory, unless you tell it differently, and that is far more often a correct assumption in my experience). Note that users need not have group write access to a file to write to that file, just to the directory that contains it. As for shared projects, they should be using CVS (or, these days, subversion) with totally separate sandboxes anyway, letting the system handle the writing within the shared repository. Note that CVS totally disregards file permissions, concerning itself only with directory permissions, precisely because they are all that actually matter for write permissions under Unix. > This is one reason why UPGs are useful. Another is the fact that > getfacl and setfacl don't work the same between Solaris, IRIX, HPUX, > etc, etc. There's a POSIX standard for this, so you can expect those differences to come into line the same way that things like pax(1) have. > Also, most admins don't know the first thing about ACLs. I still don't want to believe that. Could you provide some statistics, please? If it *is* true, it is a sign that systems administration needs some standardized certification BADLY. I wouldn't expect you could get through USENIX's tests without knowing about file ACLs. > They are not obvious when in use and end up (again, taken from my own > experience) creating more headaches and wasting more time. I have had exactly the opposite experience. > Heheheh, I would love to work where you work. I'd like to meet a user > who understands ACL's well enough to use them. Every user coming out of cs.swarthmore.edu knows about them. It is presumed by professors that you will be able to deal with them. And it should be; they're a basic and useful feature of a POSIX file system. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpX6EPLIr0hT.pgp
|
|