Creating user with username 'admin' hoses admin group, sudo config

I can confirm this bug. As Roy cautions, this bug can result in an unusable system. I was locked out of all administer functions and ultimately decided to nuke from orbit.

I also experienced this bug. At best, it's a nuisance, but it could render the system unusable for some users. It's exacerbated by the fact that it's not immediately obvious that anything is wrong--it could be some time before the user notices any problems, making it harder to identify the cause. For these reasons I'd consider this a serious bug.

It may be possible to recover, however. If you reboot and choose the recovery mode option from the boot menu, you can boot the system to a root console. You can then edit /etc/group.

You should find that most of the groups in /etc/group have sequential group ID's (GID), and are listed in order by GID. Even though the admin group's GID has changed, it may still be listed in its original order. This allows you to infer the correct GID based on those of the groups immediately before and after admin.

For example, the relevant section of the file may look something like this:
powerdev:x:115:haldaemon,johnsmith
admin:x:1006:johnsmith
gdm:x:118:

In this example, it's a safe bet that the correct GID for admin is either 116 or 117. We should search the file to see if either 116 or 117 are in use but listed out of order--the correct admin GID should not appear elsewhere in the file. In our example, if 116 is used elsewhere in the file but 117 isn't, then 117 is probably the correct GID for admin.

If you're lucky, by following this process you should narrow the options down to a single possibility. If so, change the admin group's GID to this value, ensure a user is assigned to the group and save the file.

You should also delete the admin user with the command:
 userdel admin
(This should not affect /etc/group.)

With luck, all should be well when you reboot. Of course your mileage may vary, and I accept no responsibility if this makes things worse. There may also be better, smarter ways to find the correct GID for admin, but this worked for me and I decided not to question my luck.

I just messed up a fresh xubuntu 8.04.1 install by creating an "admin" user. It should be blocked in some way.

The 'Users and Groups' gui tool got broken and pressing 'unlock' resulted in a non-descriptive error message. admin users no longer had 'administer the system' checked, though they could still use sudo at the terminal.

I fixed (well it seems fixed as far as I can see) this by creating a new admin user:

adduser newadminuser
adduser newadminuser admin

then logging out of the "admin" user and changing to the newly created user then removing the "admin" user using:

deluser admin

After this the gui tools worked again.

Looking at the source, I think this snippet:
                group = oobs_group_new (name);
                oobs_group_set_gid (group, group_settings_find_new_gid ());
is missing a check before oobs_group_new to bail out early if the name already exists in the configuration.

Also, the code flow in get_main_group() method seems strange. If gtk_combo_box_get_active_iter(...) returns True, the method seems to return the uninitialized pointer 'group'. Of course I don't know the code very well so maybe it's not a problem, but it seems suspicious.

Maybe a middle solution would be, that the admin user created by default, but locked like root.

I can also confirm this bug and I have a basic idea how to fix it:
if the GUI just checks if the group it creates already exists and if so errors or searches a solution or whatever, it should work.
So I guess this has to be forwarded to GNOME or is this up to ubuntu ?

I just had this issue on 8.10.

To clarify: As a result of creating the user "admin" in the users-admin program, the admin group in /etc/group gets replaced by a new admin group with a new gid. All of the users originally part of the admin group are obviously no longer a part of the admin group.

As a quick fix I ended up editing the /etc/group file using the only user I could (the newly created admin user) and adding "admin" and other administration users back into the admin group.

When logged in as admin before I had corrected /etc/group, I was getting an "unexpected error" in the users-admin program when I tried to "Unlock" it. Also the "Add/Remove..." menu item instantly disappeared as soon as I added it using the menu editor. Both of these issues were gone as soon as I put the new admin user in the admin group in /etc/group.

As suggested above. To fix this issue a simple check could be performed in the users-admin program to make sure a group doesn't exist already before it is created in /etc/group.

kde overcomes this problem by adding '_#' to the usergroup in case it allready exists. (ie 'admin_1').

The same problem would btw arrise as soon as you add a new user with any name where a group with this name (gui<10000) already exists. So in any case gnome shoul first check, if the GUI allready exists and if so either error or name the group differently.

I think this is a quite dangerous bug, since it affects especially inexperienced users which rely on the gui. Destroying the user groups managment with a username should not be possible.

best
Björn

sorry, it is "group" not "GUI" in my posting above.

I had just found this bug thread so I'm re-posting the following report from bug #26338:

Running Intrepid 8.10 i386.

Made the decision of adding another user with admin privileges. However while choosing a name ended up calling this new user "admin".

Stupid decision as it was, I'm to blame entirely, but the Gnome "Users and Groups" accepted without further notice. In the next boot I found out that all my sudo privileges had gone (the group "admin" vanished).

Entered the root terminal, fixed things up (I was happy to find a valid group copy in an old /etc directory, just for comparison), but kept wandering if a dumb decision like mine shouldn't be forbidden, some user names just prohibited.

Martin Pitt at Ubuntu replied:

I fully agree, the computer should be perfectly able to detect and
disallow "bad" user names. Since this bug is closed, and unrelated,
could you please file a new bug against gnome-system-tools and tell us
the bug number here? Thank you!

Just as you wrote, Björn. I've faced the bug on 8.04.2.
This is some kind of stupid joke not to check system groups before creating user one.
People are almost flying to the Mars while we have such mistakes :(

Attached is a patch for workaround - if the user enters 'admin', an error message pops up saying that it can't be done and the user is not created.

Oh, and test packages are available in my PPA.

Hi Jonathan,

thanks for the workaround.

However, I would like to suggest that the groups are checked for existance instead of an hardcoded check for "admin" since it would be an similiar problem if someone would add a user named "scanner", "pulse", "gdm" "syslog" or any other name that is equal to an existing usergroup.

best
Lion

Also marking for hardy. This sounds like a good SRU. However, I'm not happy with the patch yet:

 - It introduces new strings, which needs to be avoided for i18n reasons.
 - Hardcoding "admin" sounds wrong to me. Shouldn't it rather just check whether the user/group already exists? The current code does

   } else if (!user && login_exists (login)) {

  So what about changing login_exists() to also check for the group with the same name? That would solve the issue more generically and avoid string changes.

Tentatively assigning to Jonathan. Please let me know if you don't have time to work on this, then I'll find someone else. Thank you!

This patch for Jaunty checks if the group_exists() and returns an error saying the 'user' exists if it does. It blocks the creation of users like 'admin', 'adm', 'syslog', 'pulse', etc.

New test packages are building in my PPA.

Thanks, this looks great! Would you mind forwarding this to upstream?

I'll sponsor this in a bit.

debdiff fixes bug for me. thanks JD!

Jonathan, thanks! I'll sponsor this and take care about backporting this to intrepid and hardy. Could you please report this upstream, together with the patch? Thanks!

Jaunty tested and sponsored, works wonderfully.

Intrepid uploaded.

hardy uploaded

Accepted into jaunty-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted into hardy-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted into intrepid-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I'll copy jaunty-proposed to karmic once it's built.

Martin Pitt wrote:
> I'll copy jaunty-proposed to karmic once it's built.
>
> ** Changed in: gnome-system-tools (Ubuntu)
> Status: Confirmed => Fix Committed
>
> ** Changed in: gnome-system-tools (Ubuntu)
> Assignee: Jonathan Davies (jpds) => Martin Pitt (pitti)
>
>
Congratulations Martin...

--
L M Nicolosi, Eng.
Lat.: 23°34'4.79"S - Long.: 46°39'59.53"W
Linux Regist. User #481505 - http://counter.li.org/
5E42 E02F E21D 171B EA82 1876 621D 17EB AEBA 4B50

Upstream bug report filed at http://bugzilla.gnome.org/show_bug.cgi?id=580182 .

This bug was fixed in the package gnome-system-tools - 2.22.2-0ubuntu4

---------------
gnome-system-tools (2.22.2-0ubuntu4) jaunty-proposed; urgency=low

  * Created: 86_disable_existing_group_for_new_username.patch - disables the
    ability to create a new user whose name is owned by a perviously defined
    group, which, if allowed to happen, would overwrite the old group. If this
    happened to 'admin', for example, would render any system adminstration by
    sudoers impossible (LP: #236305).

 -- Jonathan Davies <email address hidden> Wed, 15 Apr 2009 17:56:27 +0100

jaunty-proposed copied to karmic.

Can anybody please test the -proposed packages? I tested them myself, but since I sponsored/uploaded them, we need some more eyes on this. Thanks in advance!

I tested this using Intrepid and confirm that gnome-system-tools version 2.22.1-0ubuntu1.1 does infact prevent the creation the of a user named admin and various others. Its a bit odd that the error message says the user already exists, but its the functionality that is the key.

I have reproduced the issue with gnome-system-tools in jaunty, 2.22.2-0ubuntu3, and have verified that the version in jaunty-proposed, 2.22.2-0ubuntu4, does not allow the creation of a user id that matches an id that exists solely in the group database (pulse-access is another example of this). Other user and group management continues to work.

There is still an issue that is likely difficult to solve, due it being the result of packaging policy; admins are not prevented from creating a user that later is created by a package (e,g, create a nut user/group, then install the nut package).

Running Jaunty 64 and it works. Tested for users that indeed exist.

--
L M Nicolosi, Eng.

I have also reproduced the issue with hardy's gnome-system-tools, 2.22.0-0ubuntu9, and have confirmed that the version in hardy-proposed, 2.22.0-0ubuntu10, does fix the issue as well. User and group administration continued to function.

Brian: I agree, the message reported is awkward; would it be possible to fix that in the Karmic cycle, so that an admin can adjust the default group setting in the advanced tab?

Marking verification-done.

Could someone swing by here (http://ubuntuforums.org/showpost.php?p=7164655&postcount=4) and help me fix my groups file? I accidentally walked into this bug, too, and just need help repairing the damage. I see a few fixes mentioned in the comments in this bug, but don't know what the smartest solution is.

Jamie Jackson wrote:
> Could someone swing by here
> (http://ubuntuforums.org/showpost.php?p=7164655&postcount=4) and help me
> fix my groups file? I accidentally walked into this bug, too, and just
> need help repairing the damage. I see a few fixes mentioned in the
> comments in this bug, but don't know what the smartest solution is.

Should start your system in safe mode (root) and nano edit /etc/group

Follows a segment of mine:

messagebus:x:117:
polkituser:x:118:
avahi:x:119:
haldaemon:x:120:
admin:x:121:lmario,lucio
lmario:x:1000:
sambashare:x:122:lmario,lucio
vboxusers:x:123:lucio,lmario
lucio:x:1002:lucio

below yours:

polkituser:x:118:
avahi:x:119:
haldaemon:x:120:
admin:x:1006:
jamie:x:1000:
sambashare:x:122:jamie
heidi:x:1001:

Notice there is a gap between 120 and 122 - I guess 121 used to be your
admin. Just a guess.

If I were you, after backing up the file, I would remove all references
to admin and include

admin:x:121:

and reboot and check if works.

Or better, wait for the experts opinions

Good luck,

Lucio

--
L M Nicolosi, Eng.
Lat.: 23°34'4.79"S - Long.: 46°39'59.53"W
Linux Regist. User #481505 - http://counter.li.org/
5E42 E02F E21D 171B EA82 1876 621D 17EB AEBA 4B50

Or better:

admin:x:121:jamie,[any more user w/ sup rights]

This bug was fixed in the package gnome-system-tools - 2.22.2-0ubuntu4

---------------
gnome-system-tools (2.22.2-0ubuntu4) jaunty-proposed; urgency=low

  * Created: 86_disable_existing_group_for_new_username.patch - disables the
    ability to create a new user whose name is owned by a perviously defined
    group, which, if allowed to happen, would overwrite the old group. If this
    happened to 'admin', for example, would render any system adminstration by
    sudoers impossible (LP: #236305).

 -- Jonathan Davies <email address hidden> Wed, 15 Apr 2009 17:56:27 +0100

This bug was fixed in the package gnome-system-tools - 2.22.0-0ubuntu10

---------------
gnome-system-tools (2.22.0-0ubuntu10) hardy-proposed; urgency=low

  * Created: 86_disable_existing_group_for_new_username.dpatch - disables the
    ability to create a new user whose name is owned by a perviously defined
    group, which, if allowed to happen, would overwrite the old group. If this
    happened to 'admin', for example, would render any system adminstration by
    sudoers impossible (LP: #236305).

 -- Jonathan Davies <email address hidden> Wed, 15 Apr 2009 17:56:27 +0100

This bug was fixed in the package gnome-system-tools - 2.22.1-0ubuntu1.1

---------------
gnome-system-tools (2.22.1-0ubuntu1.1) intrepid-proposed; urgency=low

  * Created: 86_disable_existing_group_for_new_username.patch - disables the
    ability to create a new user whose name is owned by a perviously defined
    group, which, if allowed to happen, would overwrite the old group. If this
    happened to 'admin', for example, would render any system adminstration by
    sudoers impossible (LP: #236305).

 -- Jonathan Davies <email address hidden> Wed, 15 Apr 2009 17:56:27 +0100