Re: [PLUG] Moving a lot of user accounts

[Brian Epstein <ep@epiary.org>]

> I disagree. The right solution to that problem is file access
> control lists, which can be managed by the users entirely without

Well, we'll have to agree to disagree, then.  ACLs don't work the same 
across OSs, or across filesystems.  And in general, most SAs wouldn't 
know a filesystem ACL if they tripped over one.  They are not obvious 
in most situations like file permissions.

> 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,

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.

> when that default causes the user's umask in their home directory
> to be 002, as it does under Red Hat Linux.

Yes, this is the whole point, and by using User Private Groups, this 
does not reduce the security of the home directory.

For example, Bob and Alice need to edit web pages.  First we create a 
new group called "web" in /etc/group, and add Bob and Alice to this 
group.

	web:x:300:alice,bob

Next, we create an area for Bob and Alice to work (as root)

	# mkdir -p /var/www/html
	# ls -lad /var/www/html
	drwxr-xr-x    2 root   root       4096 Jan 31 12:02 /var/www/html/

Now, we change the group for this directory and the permissions

	# chgrp web /var/www/html
	# chmod 2775 /var/www/html
	# ls -lad /var/www/html
	drwxrwsr-x    2 root   web       4096 Jan 31 12:02 /var/www/html/

Now as root, my job is done.

Let's see how this works in practice.  Alice creates a file in 
/var/www/html.  Her default group is "alice".

	[alice@machine /var/www/html]$ vi index.html
	[alice@machine /var/www/html]$ ls -la index.html
	-rw-rw-r--    1 alice   web       965 Jan 31 12:02 index.html

As you can see, Bob can now go in and easily edit index.html.  The
SetGID bit on /var/www/html caused the creation of index.html to set the
group to the same as the directory, "web".  Because Alice's umask was 
0002, the permissions are correctly set.

Alice's home directory is safe from outsiders because she has a User 
Private Group that she is the only member.  Therefore, her umask doesn't 
hurt her in her own directory.

> 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.

> do with forcing a default (INSECURE!) umask on users from
> /etc/profile. That's completely wrong-headed.

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.

> The quasi-right solution there is to simply educate users about
> the use of umask. The hackish solution is to use the quite-extant

Yeah, right.  How many users have you been able to educate without the 
use of a LART?

> 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.

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.

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.

> The Right solution to this problem is ACLs, and it's positively
> woeful that Linux still lacks them except in third-party file

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.  Also, most admins don't know the first thing about ACLs.  
They are not obvious when in use and end up (again, taken from my own 
experience) creating more headaches and wasting more time.

> 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

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.

Everyone is entitled to their own opinion.  I hope I haven't offended 
anyone here, but UPGs are something that I believe in.  I don't think 
they fit in every environment.  I do feel they are very effective on 
boxes in similar situations to what I described above, and warrant 
consideration in most schemes.

ep

-- 
Brian Epstein <ep@epiary.org>
Key fingerprint = F9C8 A715 933E 6A64 C220  482B 02CF B6C8 DB7F 41B4


_________________________________________________________________________
Philadelphia Linux Users Group        --       http://www.phillylinux.org
Announcements - http://lists.netisland.net/mailman/listinfo/plug-announce
General Discussion  --   http://lists.netisland.net/mailman/listinfo/plug