Why does Linux require a file/user to have a group?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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:
-n A group having the same name as the user being added to the system
will be created by default. This option will turn off this Red Hat
Linux specific behavior. When this option is used, users by default
will be placed in whatever group is specified in
/etc/default/useradd. If no default group is defined, group 1 will
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.
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.
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.
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.