gabriel rosenkoetter on Mon, 3 Feb 2003 15:54:16 -0500


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Moving a lot of user accounts


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
Description: PGP signature