Rationale of UPG (User Private Groups)

5.4. User Private Groups
Red Hat Linux uses a user private group (UPG) scheme, which makes UNIX groups easier to use.
The UPG scheme does not add or change anything in the standard UNIX way of handling groups;
it simply offers a new convention. Whenever you create a new user, by default, they have a unique
group. The scheme works as follows:
Chapter 5. Users and Groups 93
User Private Group
Every user has a primary group; the user is the only member of that group.
umask = 002
Traditionally, on UNIX systems the umask is 022, which prevents other users and other members
of a user’s primary group from modifying a user’s files. Since every user has their own private
group in the UPG scheme, this “group protection” is not needed. A umask of 002 will prevent
users from modifying other users’ private files. The umask is set in /etc/profile.
setgid bit on Directories
If you set the setgid bit on a directory (with chmod g+s directory ), files created in that direc-
tory will have their group set to the directory’s group.
Many IT organizations like to create a group for each major project and then assign people to the
group if they need to access that group’s files. Using this traditional scheme, managing files has been
difficult because when someone creates a file, it is associated with the primary group to which they
belong. When a single person works on multiple projects, it is difficult to associate the right files with
the right group. Using the UPG scheme, however, groups are automatically assigned to files created
within a directory with the setgid bit set, which makes managing group projects that share a common
directory very simple.
For example, say you have a big project called devel, with many people editing the devel files in a
devel directory. Make a group called devel, chgrp the devel directory to devel, and add all of
the devel users to the devel group.
You can add a user to a group using User Manager (see the Official Red Hat Linux Customiza-
tion Guide), or if you prefer to use the command line, use the /usr/sbin/groupadd groupname
command to create a group. The /usr/bin/gpasswd -a loginname groupname command will
add a user loginname to a group. (See the groupadd and gpasswd man pages if you need more
information on their options.) The /etc/group file contains the group information for your system.
If you created the devel group, added users to the devel group, changed the group for devel
directory to the devel group, and set the setgid bit for the devel directory, all devel users will be
able to edit the devel files and create new files in the devel directory. The files they create will always
retain their devel group status, so other devel users will always be able to edit them.
If you have multiple projects like devel and users who are working on multiple projects, these users
will never have to change their umask or group when they move from project to project. If set correctly,
the setgid bit on each project’s main directory “selects” the proper group for all files created in that
directory.
Since each user’s home directory is owned by the user and their private group, it is safe to set the
setgid bit on the home directory. However, by default, files are created with the primary group of the
user, so the setgid bit would be redundant.
5.4.1. User Private Group Rationale
Although the User Private Group (UPG) has existed in Red Hat Linux for quite some time, many
people still have questions about it, such as why UPG is necessary. To illustrate its use, consider the
following scenario.
You would like to have a group of people work on a set of files in the /usr/lib/emacs/site-
lisp/ directory. You trust a few people to modify the directory but certainly not everyone. So first
create an emacs group:
/usr/sbin/groupadd emacs
In order to associate the contents of the directory with the emacs group, type:
94
chown -R root.emacs /usr/lib/emacs/site-lisp
Now, it is possible to add the proper users to the group with gpasswd:
/usr/bin/gpasswd -a username Y
X
Chapter 5. Users and Groups
emacs
Allow the users to actually create files in the directory with the following command:
chmod 775 /usr/lib/emacs/site-lisp
When a user creates a new file, it is assigned the group of the user’s default private group. To prevent
this, perform the following command, which causes everything in the directory to be created with the
emacs group:
chmod 2775 /usr/lib/emacs/site-lisp
If the new file needs to be mode 664 for another user in the emacs group to be able to edit it, make the
default umask 002.
At this point, by making the default umask 002, you can easily set up groups that users can take
advantage of without any extra work every time users write files to the group’s common directory.
Just create the group, add the users, and do the above chown and chmod on the group’s directories.

Rationale of UPG (User Private Groups)

5.4. User Private Groups
Red Hat Linux uses a user private group (UPG) scheme, which makes UNIX groups easier to use.
The UPG scheme does not add or change anything in the standard UNIX way of handling groups;
it simply offers a new convention. Whenever you create a new user, by default, they have a unique
group. The scheme works as follows:
Chapter 5. Users and Groups 93
User Private Group
Every user has a primary group; the user is the only member of that group.
umask = 002
Traditionally, on UNIX systems the umask is 022, which prevents other users and other members
of a user’s primary group from modifying a user’s files. Since every user has their own private
group in the UPG scheme, this “group protection” is not needed. A umask of 002 will prevent
users from modifying other users’ private files. The umask is set in /etc/profile.
setgid bit on Directories
If you set the setgid bit on a directory (with chmod g+s directory ), files created in that direc-
tory will have their group set to the directory’s group.
Many IT organizations like to create a group for each major project and then assign people to the
group if they need to access that group’s files. Using this traditional scheme, managing files has been
difficult because when someone creates a file, it is associated with the primary group to which they
belong. When a single person works on multiple projects, it is difficult to associate the right files with
the right group. Using the UPG scheme, however, groups are automatically assigned to files created
within a directory with the setgid bit set, which makes managing group projects that share a common
directory very simple.
For example, say you have a big project called devel, with many people editing the devel files in a
devel directory. Make a group called devel, chgrp the devel directory to devel, and add all of
the devel users to the devel group.
You can add a user to a group using User Manager (see the Official Red Hat Linux Customiza-
tion Guide), or if you prefer to use the command line, use the /usr/sbin/groupadd groupname
command to create a group. The /usr/bin/gpasswd -a loginname groupname command will
add a user loginname to a group. (See the groupadd and gpasswd man pages if you need more
information on their options.) The /etc/group file contains the group information for your system.
If you created the devel group, added users to the devel group, changed the group for devel
directory to the devel group, and set the setgid bit for the devel directory, all devel users will be
able to edit the devel files and create new files in the devel directory. The files they create will always
retain their devel group status, so other devel users will always be able to edit them.
If you have multiple projects like devel and users who are working on multiple projects, these users
will never have to change their umask or group when they move from project to project. If set correctly,
the setgid bit on each project’s main directory “selects” the proper group for all files created in that
directory.
Since each user’s home directory is owned by the user and their private group, it is safe to set the
setgid bit on the home directory. However, by default, files are created with the primary group of the
user, so the setgid bit would be redundant.
5.4.1. User Private Group Rationale
Although the User Private Group (UPG) has existed in Red Hat Linux for quite some time, many
people still have questions about it, such as why UPG is necessary. To illustrate its use, consider the
following scenario.
You would like to have a group of people work on a set of files in the /usr/lib/emacs/site-
lisp/ directory. You trust a few people to modify the directory but certainly not everyone. So first
create an emacs group:
/usr/sbin/groupadd emacs
In order to associate the contents of the directory with the emacs group, type:
94
chown -R root.emacs /usr/lib/emacs/site-lisp
Now, it is possible to add the proper users to the group with gpasswd:
/usr/bin/gpasswd -a username Y
X
Chapter 5. Users and Groups
emacs
Allow the users to actually create files in the directory with the following command:
chmod 775 /usr/lib/emacs/site-lisp
When a user creates a new file, it is assigned the group of the user’s default private group. To prevent
this, perform the following command, which causes everything in the directory to be created with the
emacs group:
chmod 2775 /usr/lib/emacs/site-lisp
If the new file needs to be mode 664 for another user in the emacs group to be able to edit it, make the
default umask 002.
At this point, by making the default umask 002, you can easily set up groups that users can take
advantage of without any extra work every time users write files to the group’s common directory.
Just create the group, add the users, and do the above chown and chmod on the group’s directories.

inheriting correct group ownership on home linux server

Directory Set Group ID

If the setgid bit on a directory entry is set, files in that directory will have the group ownership as the directory, instead of than the group of the user that created the file.

This attribute is helpful when several users need access to certain files. If the users work in a directory with the setgid attribute set then any files created in the directory by any of the users will have the permission of the group. For example, the administrator can create a group called spcprj and add the users Kathy and Mark to the group spcprj. The directory spcprjdir can be created with the set GID bit set and Kathy and Mark although in different primary groups can work in the directory and have full access to all files in that directory, but still not be able to access files in each other’s primary group.

The following command will set the GID bit on a directory:
chmod g+s ictadmin
recursive:
chmod -R g+s ictadmin
The directory listing of the directory “spcprjdir”:

drwxrwsr-x 2 kathy spcprj 1674 Sep 17 1999 spcprjdir

The “s” in place of the execute bit in the group permissions causes all files written to the directory “spcprjdir” to belong to the group “spcprj” .

For the shared directories to work files created must be group as well as owner writeable. The default umask setting, which define the permissions on a users newly created files, need changing from 022 to 002. In  more recent versions of Ubuntu this is set in the UMASK section of /etc/login.defs

Changing persmission for unison

When you get unison complaining about wrong group when syncing:

1. To change the group of all files, folders recursive:
eg

cd to folder
sudo chgrp -R circuitadmin *

2. To change the permissions of all files, folders recursive:
eg

cd to folder
sudo chmod -R 770 *

mythlounge

  • case: Lian Li C37
  • motherboard: MSI KM3M-V (pt no. ms 7061)
  • graphics: nvidia 6200 256mb ram 64bit, low profile; using dvi-hdmi lead (Zotac: fanless). Don’t use restricted v177 (blocky video) use v173
  • network: dlink gigabit; low profile
  • ram: 1gb stick ddr
  • cpu: AMD 2800
  • hdd: 80gb ide