"User and Groups" does not inform user that manual UID already exists and create user groups.

Bug #99276 reported by sparc128 on 2007-03-31
18
Affects Status Importance Assigned to Milestone
GST
Fix Released
Undecided
Unassigned
gnome-system-tools (Ubuntu)
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gnome-system-tools

Scenario : System has 100+ accounts.
Admin adds user from "User and Groups"

Novice Admin decides for whatever reason they will specify the UID manually for the next account in the Advanced tab. They assume system will not allow duplicate UID so he does not verify UID in /etc/passwd. If the admin enters UID already assigned, GUI does not notify him that account was not created. "Users and Groups" completes the "Add User" function with no warnings or error message.

To make things worse, the following happens:

1) Personal user group is created in /etc/group.
2) GUI shows the new User Account in "User Settings".

User thinks everything is good. However, when user opens and closes the "Users and Groups" GUI, the new account disappears from the User Setting GUI.

The GUI should not be showing the new account in the first place since nothing was placed in /etc/passwd or /etc/shadow.

Performing same operation for command line tool "adduser" informs admin that account already exists.

Sebastien Bacher (seb128) wrote :

Thank you for your bug. What version of Ubuntu do you use?

Changed in gnome-system-tools:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: Unconfirmed → Needs Info
sparc128 (marcelino-mata) wrote :

Problem exists under 6.10 and 7.04. Did not verify under 6.0.6. Only tested under x86. 6.10 and 7.04 have all fixes as of March 30th.

Thanks,

Changed in gnome-system-tools:
status: Needs Info → Unconfirmed
Andre M (maroneze-a) wrote :

Similar situation occurs when an user is deleted and re-added.

Suppose you add a user "newuser" using the System -> Administration -> Users and Groups. The user is successfully created.
Then you decide to remove the user, and it is successfully removed.
Then, if you add user "newuser" again, the creation dialog works just like before, and the user shows up in the list, but it is not created. Indeed, closing and opening again the Users and Groups dialog will not show this user, nor will it be available as login.

In order to make it work again, it is needed to click on "Manage Groups" in the "Users settings" dialog, then manually remove the group "newuser". After that, it is possible to create the user successfully using the graphical interface.

However, as noted above, there are no messages indicating any errors.

Andre M (maroneze-a) wrote :

I'm sorry, I forgot to indicate this happens in Ubuntu Feisty 7.04.

jhansonxi (jhansonxi) wrote :

I just encountered this same issue on a new Feisty (7.04) install when I attempted to create a user name of "staff". As is default in Ubuntu, USERGROUPS=yes in adduser.conf so each new user gets their own group. The group "staff" is a Ubuntu default with a GID of 50 so it couldn't be used. No messages were displayed by users-admin and I didn't figure out what the problem was until I tried to use adduser which informed me the group already existed.

Iulian Udrea (iulian) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release?

Thank you,

Iulian

Changed in gnome-system-tools:
status: New → Incomplete
sparc128 (marcelino-mata) wrote :

Sure, no problem.

Problem still exists on 8.04 (64bit edition) with latest updates Feb 28 2008.

Thanks

C de-Avillez (hggdh2) wrote :

this bug looks like the same as bug 141067, only applied to users. I suggest setting it as a duplicate of 141067 (more explicit on the causes of this behaviour).

C de-Avillez (hggdh2) wrote :

correction: best match is bug 124993. Comments, anyone?

dn (nobled) wrote :

No, this is completely different from those bugs-- fixing bug 124993 just gives the admin the opportunity to work around this bug, by manually checking all the existing uid's. That shouldn't be necessary, because a smart system should warn the admin automatically.

Changed in gnome-system-tools:
status: Incomplete → Confirmed
jpcote (jp-cotegraphiste) wrote :

november 18th, in Ubuntu 8.10.
Not fixed. I've lost my admin priviledges and i can't boot anymore...need to reinstall I Guess.

jhansonxi (jhansonxi) wrote :

users-admin works much better on Intrepid (8.10). If I create a user named "admin" it takes the existing admin group (112) and reassigns it a new ID in the user range (like 1002) and adds the admin user to all the normal user groups apparently without problems as there are no messages about it. This way it provides "Windows 9x-Me" security without the annoying Vista-like security warning pop-ups. Thanks!

AmenophisIII (amenophisiii) wrote :

i have the same problem... although i did not change the uid or anything else. just the password fields.
the group of the new user gets added:
grep test /etc/group
test:x:1005:
testu:x:1006:
(i tried two times... thought maybe test is a reserved word the first time)
but no user in passwd and no home dir.
i did add users on the console before, maybe that complicated things?
no matter what went wrong.. its just a WTF NONO!!! to not do any error handling, im really pissed.

I've just fixed this problem upstream by checking that an UID free before creating the user. If that's not the case, a dialog is shown. This will sadly not be available in GNOME 2.28 because this would imply modifying strings, and that's too late for that.

The bug described in the last comment can be fixed separately and could go into 2.28 if I find how to fix it.

AmenophisIII: Actually, I can't find how the problem you describe can appear, since the tool should always choose a free UID by default. The only explanation I can find is that you have an user with ID 60000 and another with ID 60001. Could you open a separate report for that? Thanks!

This is fixed upstream with the system-tools-backends 2.9.1, which should be in Lucid soon.

Changed in gnome-system-tools (Ubuntu):
status: Confirmed → Triaged
Changed in gst:
status: New → Fix Released
Changed in gnome-system-tools (Ubuntu):
status: Triaged → Fix Committed
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  Edit
Everyone can see this information.

Other bug subscribers