severity 640894 normal
thanks
alberto wrote:
> I try to create the user "testuser" adding it to the "staff" group:
> bash:# useradd -M -g staff --password sa1aY64JOY94w testuser
You are creating a user and specifying that their initial group in
/etc/passwd is to be specified as the 'staff' group. The man page for
useradd -g says:
-g, --gid GROUP
The group name or number of the user's initial login group. The
group name must exist. A group number must refer to an already
existing group.
The key words there are "user's initial login group". That data is
not stored in the /etc/group file. It is stored in the /etc/passwd
file.
And throughout when I refer to /etc/passwd and others as files it
applies to generic database information such as NIS/YP or LDAP too.
> "id" says that all was gone rightly:
>
> bash:# id testuser
> uid=1002(testuser) gid=50(staff) groups=50(staff)
Correct. Because the entry created in the password file is:
testuser:x:1001:50::/home/testuser:/bin/sh
That number 50 in the fourth field is the staff group. When
'testuser' logs into the host it will be placed into the staff group.
> ... "groups" also confirm it:
>
> bash:# groups testuser
> testuser : staff
Correct.
> But if I check deeply, I discover that the user is not in the group:
>
> bash:# grep staff /etc/group
> staff:x:50:
You are misunderstanding the behavior of the commands here. When
useradd creates a user the group is not placed in /etc/group. It is
placed in the /etc/passwd file in the group location as the primary
group. It is not necessary to place that information in the
/etc/group file. The useradd utility used as you are using it is only
a manipulator of the passwd data and not the group data. That is by
intent and design and no manipulation of the group data is required
nor desired by that invocation.
> At this point I try to add again the user to the group using adduser:
>
> bash:# adduser testuser staff
> Adding user `testuser' to group `staff' ...
> Adding user testuser to group staff
> Done.
>
> Now the user appears in the group:
>
> grep staff /etc/group
> staff:x:50:testuser
Yes, of course, but that is a completely different behavior.
The man page for 'adduser [options] user group' says:
Add an existing user to an existing group
If called with two non-option arguments, adduser will add an existing
user to an existing group.
The general use of this is to add an existing user, which will very
typically already be in their own group (ala user private groups),
into an already existing group. That would be a secondary group not a
primary group. Using adduser to add a user to a group is a
manipulation of the group data and not the passwd data.
For example if you were to add your testuser to the adm group you
would see the following:
# adduser testuser adm
Adding user `testuser' to group `adm' ...
Adding user testuser to group adm
Done.
# grep testuser /etc/passwd /etc/group
/etc/passwd:testuser:x:1001:50::/home/testuser:/bin/sh
/etc/group:adm:x:4:testuser
# id testuser
uid=1001(testuser) gid=50(staff) groups=50(staff),4(adm)
> Another verification:
>
> bash:# adduser testuser staff
> The user `testuser' is already a member of `staff'.
Correct. The testuser has already been added to the list of groups
for staff. But that is only considering the group data.
If you had actualy tested the testuser account you would have found
the following information:
# su testuser
$ id
uid=1001(testuser) gid=50(staff) groups=50(staff)
That verifies the testuser account you created really did belong to
the staff group.
> So it seems that useradd doesn't add really the user. Moreover 'id' and
> 'groups' fail to check the user presence in the group.
No. Those statements are incorrect due to your misunderstanding of
how the system is working. The useradd command has created a user and
has placed it in the staff group. This is a manipulation of the
passwd data in the /etc/passwd file. The id and groups commands
understood this properly and reported the correct information. No
changes to /etc/group were requested nor were they needed as evidenced
by the id and groups commands.
I changed the severity from important to normal so as not to encourage
bug severity inflation. But since this is not a bug in any of the
utilities under discussion I expect that it will be closed as such.
Since in any case both coreutils programs id and groups were obviously
behaving correctly. Your only issue seemed to have been with the
'useradd' command from the passwd package and not coreutils.
Bob
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
