Hello Experts,


A normal user tries to login onto Linux (SuSE) System who has his/her account on it. What happens if somehow the primary group which it belongs to, does not exist.
Will the system allow him to get in simply because his account exist or will it deny access?
I have tested this on a test system...I created a local user and changed his group-id to some arbitrary number in /etc/passwd File. The system still allows him to login without any problem and id command shows his primary group as this nonexistent number. So I feel system has no problem what so ever if his group-id has any meaningful association on system. Is it really so?
Does this as well hold true for NIS or LDAP Authentications?
Thanx in advance.

Regards,
Admin

AFAIK the kernel and the filesystem are concerned only with UID and GID. The user and group names are for the convenience of humans. Any program that needs to show a name uses /etc/passwd or /etc/group to find out what the name is. Otherwise, it uses some substitute. For example, if your user creates files and then uses ls -l to list them, you will see the group owner given as a number.

In LFS, when you first chroot into your new system, you get the bash prompt "I have no name" because there is no /etc/fstab as yet, so bash doesn't know that user 0 should be called root. But you still have full root powers because that goes with with the UID 0.

1 members found this post helpful.

Correct: a group-id (like a user-id) is a number. If that number is not listed in /etc/groups then it will show only as a number and will not have a name.

Thanks Hazel and sundialsvcs for your replies. I agree that the system recognises User Accounts with IDs and not with names. But my question was, what if that GID (Group) does not exist on the system at all?

For example for testing if I create a group called city with gid 1011 and create a user called sam with primary group city. And then later, delete that group(and its GID) will that user be able to login as its primary group does not exist.

It seems from my tests , he was still able to login. Ofcourse when he created files, they all have now 1011 as their gids. But login is permitted.

No, you still don't get it. What you have deleted is the record in /etc/group that just assigned a human readable name to the GID (well, technically, /etc/group can do more, but not in this case). The home directory of sam is still owned by the GID 1011 even if it doesn't have a name now. Check it with
Also, if you look it up in /etc/passwd, you'll see that the primary GID of sam is still 1011:

2 members found this post helpful.

"A group" is "a group-id." That is to say, it is a number. If you associate a name with that number you will see it listed by name. But it can actually be any number that you want. Its only purpose is with permission-checking. There is no physical or logical resource otherwise associated with "a group."

"User ids" are also numbers, but they have to appear in the (shadow ...) password table. Users also have other characteristics and resources associated with them, such as "home directories." And, a list of group-ids.

1 members found this post helpful.

Thank you all (hazel, shruggy & sundialsvcs) for your valuable comments and suggestions. It is now clear. This Post can be marked as closed.