gabriel rosenkoetter on Mon, 03 Feb 2003 01:50:29 -0500


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

Re: [PLUG] Moving a lot of user accounts


On Sun, Feb 02, 2003 at 10:56:21PM -0500, Brian Epstein wrote:
> I have to disagree with you on this point (being in left field).  
> Although User Private Groups are not helpful in all production
> environments, it works extremely well when users need to share a common
> directory (like if you have a web team instead of a web admin).  Most 
> production boxes I've worked on that require user accounts also require
> file sharing between those user accounts.

I disagree. The right solution to that problem is file access
control lists, which can be managed by the users entirely without
administrative influence (adding one user to the other user's
default group).  Failing that, a task-specific group is far more
appropriate than adding a user to another user's default group,
when that default causes the user's umask in their home directory
to be 002, as it does under Red Hat Linux.

The point is, if users foo and bar want to get at the same set of
files, NEITHER should own those files, and their shouldn't be groups
foo and bar, and you have to add user foo to group bar, wasting the
utility of group foo (and limiting the usefulness of foo's group
access, since there's a hard limit on the number of groups of which
a user can be a member; 16, most places). If these two are doing
cooperative web development, then it's far more reasonable that
there be a group web of which they are both members.

> Here's a good writeup on why RH does this.
> 
> http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-users-groups-private-groups.html

What they say under "User Private Group Rationale" has absolutely
nothing to do with creating a group for each user, and everything to
do with forcing a default (INSECURE!) umask on users from
/etc/profile. That's completely wrong-headed.

The quasi-right solution there is to simply educate users about
the use of umask. The hackish solution is to use the quite-extant
dot-file-processing techniques within the directories where umasks
should be something specific to set those umasks. This doesn't take
an shell-specific dances (except between Bourne shells and C shells,
but you're already carefully setting things up for both, right?), it
just takes some infrastructure in /etc/profile, and, even if it's a
bit more work, is far less of a blunt instrument than a forceful
umask 002.

The Right solution to this problem is ACLs, and it's positively
woeful that Linux still lacks them except in third-party file
systems (XFS and AFS). ACLs mean that I, as the sysadmin, need not
be involved for users to share files. Clearly, there's no reason I
should be, except that the old-fashioned (BSD) permission system
forces that. Well, fine, so the design is broken, and we've got a
better way of doing it: ACLs.

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgpMSTaeVVE4w.pgp
Description: PGP signature