Why does Linux require a file/user to have a group?
 

When I create a new user, a primary group is created with the same name as the username. I can then add the user to other secondary groups if desired.

When I create a file, the username defaults to my username, and the group defaults to my group.

I am sure I am wrong, but if I developed Linux (and probably Unix), I would not have a primary group for the user, but only the secondary groups. For files, I would allow the file to have group NULL.

I am sure there were good reasons to do what was done, and am curious what they were.

Thank you

Actually not all Linux distros create primary group with same name as user. Also you can prevent this from happening by adding the "-n" flag to the useradd ccommand. From the useradd man page:

Thank you MensaWater,

But even is this case, the user will either be placed in whatever group is specified in /etc/default/useradd, and if no default group is defined, group 1 will be used. What is the purpose of the primary group, and why not just use secondary groups? In regards to files, why create some fictional "nogroup" but instead not have a group assigned to the file?

Maybe the answer is simply "it is that way just because", but more often there seems there is always a good reason things were done the way they were.

Other than ideal curiosity, I am developing a PHP app which will mimic some of the Linux user/group/permissions functionality.

Thanks again!

It's pretty much "just the way it is, and has been from the beginning." It's why we end up with a UID and GID for user "nobody" for when we want a process to run without any special permissions.

Thanks rknichols, Think it should have been that way?

Writing kernel and user space code to handle special cases like "file with no UID" or "user with no GID" is a pain. It also brings up questions like, "What can a user do with a file that has no UID? All things?? Nothing??" There is already one special UID (0 = "root"). Having more special cases makes the problem grow exponentially. Consider also what you would have to write everywhere you explain the permissions system.

That's just the way it is as they say. The reasons go back to UNIX which has been around since 1970. UNIX was designed to be "multiuser" so users have been there since inception. Whether groups were added later or there always I don't know but they were certainly there as long ago as the mid-80s when I first worked on AT&T Unix. It may have had to do originally with "accounting" as in early days it was very important to track who did what if for no other reason than so you could charge that department for using (originally) very expensive computer time.

It does go back to 1970...

But the reason the file is given a group is that it MUST have a group value.

Because the group defines access controls putting in a generic group (such as null), means the group name "null" must be given a group identification number.

Unfortunately, putting in a null group means that anyone that has access to the null group may also access that file... even when they shouldn't. It is very much like having a login with a null password...

Various distributions have slightly different policies when it comes to groups. RH/Fedora/CentOS tend to create a group with the same name as the user. This allows the group access to be equivalent to the user, thus protecting the file from accidental exposure.

Other systems may use the first group in the users list... And that first group is always the one assigned in the /etc/passwd file (or LDAP/NIS/... wherever the authorization record comes from.

The user can always change the default group - that is what the "newgrp" command does.

You can use the "id" command to list the defaults and groups the user is authorized to use.
Then the newgrp will change the default group to any other group the user is authorized.

BTW, there is already a "nobody" group (two of them for that matter). "nobody" is given the UID/GID of 99, and the "nfsnobody" is given the UID/GID of 65534. These two accounts are used for specific purposes - "nobody" is used for processes spawned by the system that are specifically isolated. They are given one of these two uid/gid values because they are not supposed to be used by any account. The nfsnobody is used by NFS network services for any account that doesn't exist within the client or server. No files SHOULD get those ids (at least not writable anyway) as they are used to indicate user mapping failures.

Thank you MensaWater and Senior Member,

I think I understand the reasons why the group "shouldn't" be null. I didn't say "couldn't" as it seems the group identification number could also be null and the kernel could deal with it, but that likely causes also problems. Bottom line, I agree with you.

I started off typing this response planing on also asking why would one need a primary group as well as secondary groups. Is there any difference between user John who's primary group is Group1 and who's only secondary group is Group2 than user John who's primary group is Group2 and who's only secondary group is Group1? (note that this is not entirety a rhetorical and I would appreciate an answer). But if the primary group field did not exist, there would be no group to assign the newly created file which goes against what I previously agreed with you should be done in the preceding paragraph.

So, it is not "that way just because", but there was a good reason to do so.

The difference is that, by default, files get created with the GID of the creating process's primary group. The owning UID can change the file's GID to any group of which that user is a member, and the "setgid" bit on the directory would cause the directory's GID to be the GID for files created there, but the default would be the user's primary GID. A user can also use the newgrp command to change the current primary group to any group of which he is a member or, in the uncommon case of group passwords being set, to any group for which he knows the password.

Thank you rknichols,

I suspected most of this, but you taught me more.

Michael