Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

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.

share|improve this answer

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.

share|improve this answer

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.

References

= OpenGroup POSIX docs mentioning GID

share|improve this answer
    
(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) –  Scott Jul 16 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) –  Scott Jul 16 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. –  Scott Jul 16 at 15:23
    
P.S. Old joke: The real UID and GID are ineffective, and the effective UID and GID are unreal.  :-)     ⁠ –  Scott Jul 16 at 15:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.