Among the metadata kept by traditional unix systems for a file, there is:
- a user ID identifying the owner of the file;
- a group ID identifying the group that owns the file;
- permission bits for the user, for the owning group, and for others.
The sole effect of the group ID of a file (except for directories as described below) is to determine effective permissions. When a process tries to access a file:
- if that process is running as the user owning the file, user permissions apply;
- otherwise, if the process has the group owning the file as one of its effective or supplementary groups, then group permissions apply;
- otherwise “others” permissions apply.
Many modern unices support access control lists which extend on these rules.
When a file is created, its owner is set to the effective user ID of the process that created it. One of two rules are applied to determine the group owning the file:
- BSD semantics: the file belongs to the group owning the directory;
- System V semantics: the file belongs to the effective group ID of the process that created it.
Linux and many other modern unices apply System V semantics unless the group has the setgid bit set, in which case BSD semantics are applied. The owner and group can of course be changed later with
Normally the effective group ID of a process is the primary group of the user who started the process. This is the group listed in
/etc/passwd, if using a local user database. On Linux, you can see it with
getenv passwd $USER where
$USER is your username (or any other username). The primary group ID is the fourth colon-delimited field.
Depending on your distribution, by default, either all users are in the same group (commonly called
users), or each user gets his own group of the same name as the user. Enterprise networks often sort users into groups according to which department they work for or which role they have, e.g.