creating new user account silently fails when UID is already used

Bug #372695 reported by FernanAguero
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GST
Fix Released
Undecided
Unassigned
gnome-system-tools (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

As a system administrator, if you try to create a new account, using the graphical utility (System->Administration->Users and Groups) and you set the user id manually to a value that is already in use by another user, the program will silently ignore the action (it will show the new user in the list, but if you close the utility and reopent it again, the new user is gone -- and it never really gets written in /etc/passwd).

The problems, as I see them, currently are:

1. The utility allows you to set the user id to a value that is already in use without giving a warning
2. The utility shows you a list of users that is not a real reflection of /etc/passwd

How to reproduce it:
1. Inspect /etc/passwd and look for an existing user account. Take note of its user id (usually 1001 would work)
2. Open the Users and Groups tool, create a new user and in the Advanced tab, set the user ID to this number (1001)
3. See how the new user is shown in the list of users
4. Close the Users and Groups tool
5. Open the users and Groups tool
6. Verify that the new user does not exist.

Tried it in Ubuntu-9.04 (Jaunty)

Revision history for this message
FernanAguero (fernan-ciudad) wrote :

Also, if you add a user and then delete it, you can never add it back again.

How to reproduce it.

1. Create a new user, and close the Users and Groups utility

username: test
userid: 1030

Log out from your admin account, and log in with your test account, just to check that everything works fine.
Log out from your test account and log back in as an admin.

2. Delete the test account with the Users and Groups utility, and try to create a 'test' user again, if you want you can close and open the Users and Groups utility again.

It tells you that you cannot add a 'test' user because it already exists.

3. Just to recheck that this is a bug.

The home folder for this user is still there, which may prevent us from creating a user with this name, so we delete it:

sudo rm -rf /home/test

Also we check if /etc/passwd refers to this account:

grep -c test /etc/passwd
0

No traces left from the 'test' user (or so it seems), however, the Users and Groups utility still doesn't allow us to create this account 'because it already exists'

Current problems with this utility:

I cannot fix a mistake:
What if I made a mistake and want to bring this user back to life?

The utility does not help me get rid of all files referenced or referring to this account:
What if I really want to create a new, fresh account with this same username/userid combination?

Revision history for this message
Brian Murray (brian-murray) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage. I have classified this bug as a bug in gnome-system-tools.
For future reference you might be interested to know that a lot of applications have bug reporting functionality built in to them. This can be accessed via the Report a Problem option in the Help menu for the application with which you are having an issue. You can learn more about this feature at https://wiki.ubuntu.com/ReportingBugs.

affects: ubuntu → gnome-system-tools (Ubuntu)
Revision history for this message
Brian Murray (brian-murray) wrote :

I was able to recreate this using gnome-system-tools version 2.22.2-0ubuntu4 on Jaunty.

Changed in gnome-system-tools (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Changed in gnome-system-tools (Ubuntu):
assignee: nobody → Milan Bouchet-Valat (nalimilan)
summary: - create new user account silently fails
+ creating new user account silently fails when UID is already used
Revision history for this message
OE (onno-ebbinge) wrote :

I can confirm the findings of "FernanAguero".

The fix is:
- delete the home dir
- remove from /etc/group
- remove from /etc/gshadow

Now you can recreate a user you have deleted.
Good starting point for the devs.

Regards,
OE

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

In 2.29.2 we let adduser choose the free UID for us, so that won't happen anymore. Should be in Lucid soon.

Changed in gst:
status: New → Fix Released
Changed in gnome-system-tools (Ubuntu):
status: Confirmed → Triaged
assignee: Milan Bouchet-Valat (nalimilan) → nobody
Changed in gnome-system-tools (Ubuntu):
status: Triaged → Fix Released
status: Fix Released → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-system-tools - 2.29.3-0ubuntu1

---------------
gnome-system-tools (2.29.3-0ubuntu1) lucid; urgency=low

  * New upstream release (LP: #506365)
    - Move to new System Tools Backends protocol (new liboobs API).
      We now only commit changes to one user at a time, reducing the
      risk for dangerous bugs.
    - Include default profiles configuration file (user-profiles.conf).
      Distributors should modify it to suit their needs and send them
      back for inclusion.
    - When creating an user, don't force UID, main group, home directory
      and shell: these parameters are now handled (better) by the platform
      tools (LP: #488158, LP: #313990)
    - Allow removing home directory when deleting an user (LP: #426125).
    - Don't allow deleting the last administrator account, and warn when
      the user is losing its own admin rights. Same for active users
      (LP: #25947, LP: #349453)
    - Don't allow creating a group with an existing GID (LP: #491434)
    - Use UID and GID ranges defined by liboobs, depending on the platform's
      abilities.
    - Clear suggested login entry when Real name is emptied in the new user
      dialog.
    - Change GConf "showall" option to apply only on users. System groups are
      always shown, since they are the most interesting ones.
    - Various UI and string improvements.
    - Change password for current user by running 'passwd', to avoid
      breaking keyrings and encrypted dirs
    - Ask for PolicyKit authentication when it most makes sense, i.e.
      when showing dialogs
    - Option to set encrypted home directories when creating users (on
      platforms that support it) (LP: #302870)
    - When editing one group, only commit changes to that group
    - When changing Real name, update it in the users list (LP: #498970)
    - Select current user on start, and the first one after selected user
      has been deleted
    - Don't force updating configuration twice on start
  * Also fixes LP: #344182, LP: #208057, LP: #188757, LP: #372695,
    LP: #99276, LP: #160862
  * debian/control:
    - Bump liboobs-dev build-dep to 2.29.3
  * debian/gnome-system-tools.install:
    - Don't install debian/profile
    - Install upstream user-profiles.conf instead
  * Delete debian/profiles
  * Refreshed patches:
    - 25_sambashare_group_definition.patch
    - 90_relibtoolize.patch
  * Dropped debian/patches/85_user_gnome_about_me_for_password.patch:
    - The change is obsolete in the new version
  * debian/patches/82_gst-packages-time-admin.patch:
    - Updated to remove superfluous UI file changes, causing focus issues
      in the users-admin password change dialog. Thanks to Will for
      spotting this (LP: #501976)
 -- Chris Coulson <email address hidden> Fri, 05 Feb 2010 15:30:10 +0000

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

Other bug subscribers

Remote bug watches

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