The How and Why of User Private Groups in Unix

The first time I heard about User Private Groups (UPG) is when I was installing one of my first Red Hat Linux systems when I was in college.  As a seasoned Solaris administrator, I thought it was very odd that Red Hat didn't put my users into a default group of staff.  And then they wanted to change my umask from 022 to 002?  What the heck, that doesn't sound secure?

I remember going through and reverting that first Red Hat system back to the old way I was used to and wondering why this new OS was doing something weird.  A few weeks later I read up on User Private Groups and got a glimpse of how and why they work and their benefit for systems administrators and Unix users.  Afterward, I started moving my Solaris machines to User Private Groups, and reverting the Red Hat machine back as well.

Here is a page out of RedHat's 7.3 user manual.  This was the earliest mention I could find for UPG, although I do not know if Red Hat invented it themselves.

The problem that UPG tries to solve is shared directories between different users.  To do this securely on a Unix machine, you really need to setup a group for the users to be members of, and then keep the files in the directory owned and writeable by the members of the group.

Let's take the example of a shared web directory where multiple users edit web pages.

Typically, pre-UPG, users were primary members in a staff group, and then secondary members in auxillary groups, like "web" for our example.  Their umask was 022, so new files would be created 644 and directories 755 (users read,write; group read only; other read only).  The administrator would have to create the directory for the users to work in and make that directory group owned by web and group writeable.

# mkdir /var/www/html
# ls -ld /var/www/html
drwxr-xr-x. 5 root root 4096 1997-12-07 17:00 /var/www/html/
# chown root:web /var/www/html
# chmod 775 /var/www/html
# ls -lad /var/www/html
drwxrwxr-x. 5 root web 4096 1997-12-07 17:00 /var/www/html/

Now at this point, the sysadmin would sit down with their users and say, "Ok, play nicely.  If you create a file, make sure to change the group to web, and set the group write permission on the file.  Otherwise, your coworkers won't be able to edit the files."  At which point the users would say, "sure", but in the back of their mind say, "whatever, just let me write some HTML, I'm behind."

So, now Bob wants to create a webpage

bob:~$ cd /var/www/html
bob:/var/www/html$ vi index.html

He loads up his web browser, and it's there and looks good.  Great, he logs out and goes home.  The next day, Bob is sick and stays home.  Alice finds that Bob misspelled the companies president's name and goes in to edit the file.

alice:/var/www/html$ vi index.html
"/var/www/html/index.html" E212: Can't open file for writing
alice:/var/www/html$ ls -l index.html
-rw-r--r--. 1 bob staff 2614 2009-10-05 11:46 index.html

"Darn, Bob didn't change the group ownership and permissions on the file.  I can't edit it, now I have to contact the sysadmin.  He's gonna be upset."  This is the saga that plagued sysadmins that eventually lead to the idea of UPGs.

In a UPG setup, each user is put into their own private group.  So, Bob has a group called bob, and Alice has a group called Alice.  This is their default group.  Whenever Bob creates a file in his home directory, the group ownership is "bob" instead of "staff".

The reason why we do this is so that we can change the umask from 022 to 002.  So, new files are created with 664 (owner read/write, group read/write, other readonly). 

By using a private group, we aren't exposing Bob's files to being overwritten by Alice.  If Bob's default group was still staff with a umask of 002, Alice would be able to edit files in his home directory.

Now, the next part of this puzzle is the set_gid bit.  From the coreutils info page, the following happens when setting the set_gid bit on a directory:

On most systems, if a directory's set-group-ID bit is set, newly
created subfiles inherit the same group as the directory, and newly
created subdirectories inherit the set-group-ID bit of the parent

So, by setting the set_gid bit on the /var/www/html directory, it would force new files and directories to be created with the group of the directory.  So, after creating a bob group and an alice group and assigning them as the default groups for bob and alice, the administrator does the following (the last two commands just clean up the mess that Bob and Alice were in before):

# ls -ld /var/www/html
drwxrwxr-x. 5 root web 4096 1997-12-07 17:00 /var/www/html
# chmod g+s /var/www/html
# ls -ld /var/www/html
drwxrwsr-x. 5 root web 4096 1997-12-07 17:00 /var/www/html/
# chgrp -R web /var/www/html
# chmod -R g+w /var/www/html

Now, let's see what happens when Bob creates a new file.

bob:~$ id
uid=523(bob) gid=523(bob) groups=101(web)
bob:~$ umask
bob:~$ cd /var/www/html
bob:/var/www/html$ vi index.html
bob:/var/www/html$ ls -l index.html
-rw-rw-r--. 1 bob web 2614 2009-10-05 11:46 index.html

And now when Alice needs to make a change to the file

alice:~$ id
uid=524(alice) gid=524(alice) groups=101(web)
alice:~$ umask
alice:~$ cd /var/www/html
alice:/var/www/html$ vi index.html

As you can see, Bob and Alice can work safely on the same files and concentrate on writing HTML instead of remembering to change permissions and groups of files.  And the sysadmin isn't constantly being bothered^H^H^H^H^H^H^H^Hasked to change permissions on files.

UPGs don't allow users to create groups on the fly by themselves, though.  They still need the sysadmin to create the group and the directory and initially set the directory to be writeable by the group and set_gid.  I'm sure some set_uid programs could be written to allow the user to do this themselves, but it opens up a can of worms for the sysadmin.

Anyway, I hope this clears up how UPGs work and why they were created.

Have fun!