As far as I understand the users in Unix system can belong to multiple groups and one of them will become the primary group for that user. Others will be supplementary groups. All of this User/Group infrastructure is facilitated by /etc/group and /etc/passwd files.

Now group permission of the user is determined exclusively by the active group which can be changed by newgrp command. The active group on login is the primary group defined in /etc/passwd file. So the question is what is the fundamental reason on why the designers chose to have this concept of a single active group even though allowing the user to have more than one supplementary groups? What would be the issue if all the groups were active simultaneously?


3 Answers 3


All groups are active at all times.

You can access any file that any of your groups can access. But when you create a new file/process it is created using your primary group, unless setgid or ACL defaults are in use.

  • Not exactly. I just had the case that another user tried to make available a folder to me 705 permission but I did not work because both folder and myself are in the group "users". The fact that I am also in some other groups did not automatically allow me to get in. (I didn't try changing my active group. It was easier to ask the colleague to change permissions to 755.) Jul 4, 2018 at 6:49
  • 2
    @JoachimWagner What happened to was. The OS checks if you are the owning user, then the owning group, it then checks group permissions and says no (It only ever checks one set of permissions). And other has nothing to do with other-groups. Other means those that are not this owning user and are not in this owning group. It Does not mean, if user is a member of another group. Therefore Your comment does not contradict my answer in any way. Jul 4, 2018 at 8:42
  • Thanks. I found a nice description later saying to read 705 as "everyone except members of this group". Jul 6, 2018 at 11:43

One reason: when one creates a file, it can be only in one group, and this group is not specified during the file creation. So, there must be a notion of single active group.


Q1: So the question is what is the fundamental reason on why the designers chose to have this concept of a single active group even though allowing the user to have more than one supplementary groups?

The original primary purpose of groups in Unix was to allow for sharing of access to files on disks. Within this use case you'd typically be accessing your files the majority of the time, and occasionally be accessing files that were shared among a group of users.

So my suspicion is that it was designed around this model to start. Over time this model has been modified, but the general approach remains intact, that you're in a primary group (specified in /etc/passwd) and you have supplementary groups that you can be a member of (specified in /etc/group).

Several of the earlier implementations (such as on Sun/Solaris) included a limit of ~15 groups total that a user could be a member of when using NIS+.

Q2: What would be the issue if all the groups were active simultaneously?

There are a number of system calls within POSIX that expose an API with this design, hence it would probably be a large task to modify it, given the amount of software that's built around it at this point. And there really isn't any reason to change it either.

The other big limitations are the file system and process space. For filesystems, these generally include only a single value for the GID that a given file or directory is to be "grouped" to. Same too for processes that are running. They're typically associated to a single group.

However, this overall approach has been able to adapt to being integrated with Active Directory and other credential technologies over time, so it's a perfectly fine implementation, though a little strange when you first learn about it.


= OpenGroup POSIX docs mentioning GID

  • (1a) You may know this, but it’s not clear (to me) from what you wrote, so let me clarify: In the beginning (the early 1970s), a Unix process had a real UID, an effective UID, a real GID, and an effective GID. Period.  Processes didn’t have supplementary groups.  A user could belong to multiple groups.  That allowed her to use the newgrp command to switch into any of her groups; this worked in a way much like the way su lets you switch into another user (UID).  … (Cont’d) Jul 16, 2015 at 15:21
  • (Cont’d) …  So, if your primary group was red, and you also belonged to blue and green, and you wanted to read a file that was owned by somebody else, with a group of blue and a mode of 640, you would need to say newgrp blue first.  If you wanted to compare (i.e., diff) a blue (640) file and a green (640) file, you would need to make a copy of one of them first.  (It was very inconvenient.)  The idea that a process could be in multiple groups simultaneously didn’t come along until later; at least the late 1970s, maybe the early or mid 1980s.  … (Cont’d) Jul 16, 2015 at 15:22
  • (Cont’d) …  (1b) I wasn’t involved in the development of Unix, but I can imagine that the developers thought that eliminating the primary real GID and effective GID and replacing them with a group list (rather than just adding the supplementary group list, as they did) would break too many legacy programs by (unnecessarily) removing parts of the kernel API.  (2) Your OpenGroup link doesn’t do what you say it does (damn them and their frames interface).  Try pubs.opengroup.org/cgi/kman4.cgi?value=gid. Jul 16, 2015 at 15:23
  • P.S. Old joke: The real UID and GID are ineffective, and the effective UID and GID are unreal.  :-)     ⁠ Jul 16, 2015 at 15:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .