| gabriel rosenkoetter on Mon, 03 Feb 2003 01:50:29 -0500 |
|
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
|
|