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

Bug #236305 reported by Roy Badami on 2008-05-31
96
This bug affects 7 people
Affects Status Importance Assigned to Milestone
GST
Fix Released
Critical
gnome-system-tools (Baltix)
Undecided
Unassigned
gnome-system-tools (Ubuntu)
Critical
Martin Pitt
Hardy
Undecided
Unassigned
Intrepid
Undecided
Unassigned
Jaunty
Critical
Jonathan Davies

Bug Description

If you create a new user in the User and Groups tool, and specify 'admin' as the username, this ends up deleting the existing admin group when it creates the new user's group. The most visible effects of this is are that sudo stops working, and that it is no longer possible to administer the system using the GUI tools.

N.B. before attempting to repeat this, take a backup of /etc/group, and verify that you have means to gain root without using sudo!

Similar problems, although less visible, might exist when creating users whose username matches any existing group; however I have not verified this.

Observed in Hardy.

Brian Fallik (bfallik) wrote :

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.

Brian Fallik (bfallik) on 2008-08-04
Changed in gnome-system-tools:
status: New → Confirmed

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.

jharkn (jh6348) wrote :

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.

Brian Fallik (bfallik-litl) wrote :

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.

Hrotkó Gábor (roti-al) wrote :

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

Bert Van de Poel (bhack) wrote :

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 ?

Komoto (komoto) wrote :

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.

Björn Rabethge (b-rabethge) wrote :

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

Björn Rabethge (b-rabethge) wrote :

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

Lucio M Nicolosi (lmnicolosi) wrote :

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 :(

Jonathan Davies (jpds) on 2009-04-15
Changed in gnome-system-tools (Ubuntu):
importance: Undecided → Critical
Jonathan Davies (jpds) wrote :

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.

Jonathan Davies (jpds) wrote :

Oh, and test packages are available in my PPA.

Björn Rabethge (b-rabethge) wrote :

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

Martin Pitt (pitti) wrote :

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.

Martin Pitt (pitti) wrote :

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!

Changed in gnome-system-tools (Ubuntu Jaunty):
assignee: nobody → Jonathan Davies (jpds)
Jonathan Davies (jpds) wrote :

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.

Martin Pitt (pitti) wrote :

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!

Martin Pitt (pitti) wrote :

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!

Martin Pitt (pitti) wrote :

Jaunty tested and sponsored, works wonderfully.

Changed in gnome-system-tools (Ubuntu Jaunty):
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

Intrepid uploaded.

Changed in gnome-system-tools (Ubuntu Intrepid):
status: New → In Progress
Martin Pitt (pitti) wrote :

hardy uploaded

Changed in gnome-system-tools (Ubuntu Hardy):
status: New → In Progress
Changed in gnome-system-tools (Ubuntu Jaunty):
status: In Progress → Fix Committed
tags: added: verification-needed
Martin Pitt (pitti) wrote :

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!

Changed in gnome-system-tools (Ubuntu Hardy):
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

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!

Martin Pitt (pitti) wrote :

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!

Changed in gnome-system-tools (Ubuntu Intrepid):
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

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

Changed in gnome-system-tools (Ubuntu):
assignee: Jonathan Davies (jpds) → Martin Pitt (pitti)
status: Confirmed → Fix Committed

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

Jonathan Davies (jpds) wrote :
Changed in gst:
status: Unknown → New
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-system-tools (Ubuntu Jaunty):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

jaunty-proposed copied to karmic.

Changed in gnome-system-tools (Ubuntu):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

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!

Changed in gnome-system-tools (Ubuntu Jaunty):
status: Fix Released → Fix Committed
Brian Murray (brian-murray) wrote :

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.

Steve Beattie (sbeattie) wrote :

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).

Lucio M Nicolosi (lmnicolosi) wrote :

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

--
L M Nicolosi, Eng.

Steve Beattie (sbeattie) wrote :

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.

Steve Beattie (sbeattie) on 2009-04-27
tags: added: verification-done
removed: verification-needed
Jamie Jackson (jamiejackson) 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.

Lucio M Nicolosi (lmnicolosi) wrote :

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

Lucio M Nicolosi (lmnicolosi) wrote :

Or better:

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

Launchpad Janitor (janitor) wrote :

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

Changed in gnome-system-tools (Ubuntu Jaunty):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-system-tools (Ubuntu Hardy):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-system-tools (Ubuntu Intrepid):
status: Fix Committed → Fix Released
Changed in gst:
importance: Unknown → Critical
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.