[users-admin] Changing UID doesn't work

Much thanks for the report. This was indeed a mistake : we were identifying users using their UID instead of their login. When changing their UID, we weren't able to find the user to apply the new settings to. It's now fixed upstream and will be available in the system-tools-backends 2.10.0, for Lucid.

Please continue testing Lucid and reporting bugs! May I give you an advice? Please stay very specific about the bug you report. For example, here, the bug is not that you can't hide users in GDM: this is just a consequence of the bug. The precise problem is that changing UID is not working as it's supposed to be. This will help triagers and developers to fix the bugs you find.

Fixed with 2.10.0, not yet in Lucid though.

Will g-s-t also adjust the ownership of files in the filesystem upon changing a user's ID, or would that be a different issue?

Is gst using usermod? Its manpage says:

 -u The ownership of files outside of the users home directory must be
           fixed manually.

No, changing files' UID would be a different bug. There's support in the backends for changing UID of the home directory, but that's not used ATM (will be easy to fix for the next release). But for files outside of the directory, there's no support in the backends ATM. That's kind of a corner case, so if you want this to happen, you should have a look at the perkl code yourself... ;-)

Will the bug be solved in Lucid? It is still there, since it is still package version 2.9.4 of the system-tools-backend.

Thanks, Simon

Temporary workaround:

As suggested by Milan Bouchet-Valat in bug #553746:
> Note if you really need a specific profile for some users, have a look at
> /etc/gnome-system-tools/user-profiles.conf, where you can add MinUID and MaxUID options.

I needed a user with a UID of 1248 and this is what I did:
* Applied the patch. (Notice that the number 1248 - the desired UID is in the patch - adjust to your own needs)
* Created a new user
* Removed the patch again

Now I have a user with UID 1248. Note, that this is only useful for creating new users, not modifying existing ones.

BTW, how does anybody use NFS with more than one user if it isn't possible to modify the UIDs? I see this as NFS' gravest shortcoming.

No need for this workaround - you'd better edit /etc/passwd and /etc/group directly. For the proper fix, we just need to package system-tools-backends 2.10 to Lucid.

Hmm. That isn't the only thing, is it?

I guess at least one would need to:

# chown -R user: /home/user
(or perhaps
# chown -R user:user /home/user
)

after the user ID and groupID have been edited. Do we agree on that?

Anything else?

Peter

Let's be clear: the fix is known upstream for ages, see my comment #2 above. So no need to discuss it again, you just have to find somebody willing to upload the version to Lucid.

The question of whether we should chown the home directory is another problem, which could be easily solved using the $chown_home flag, but the GUI should ask before doing so, since people may not expect this behavior (e.g. home directory shared between several users). So file a different report if you want this to happen.

In order to be clear:

Bug #553746 "Cannot Change User and Group ID" is marked as a duplicate of this one (by Milan, btw), Which is why I'm commenting here.

In the original text for that that bug, it says:
> Furthermore, adding a new user gives you no opportunity to set the User ID.

And that is what _I_ need: A new user with a specific user ID. (I have to connect to an NFS volume, where my files already pre-exist with a specific user and group ID - 1000 or 1001 just won't cut it)

Perhaps my situation isn't relevant for this bug, and I should open a new bug for setting the User ID when creating a new user.

But anyway, for my situation, I guess I'll create the new user and group, hand-edit /etc/passwd and /etc/group and then do something like this:

sudo find / -o -uid $olduid -print0 | sudo xargs -0 chown $newuid
sudo find / -o -uid $oldgid -print0 | sudo xargs -0 chgrp $newgid

Damn, a typo. Make that:

sudo find / -o -uid $olduid -print0 | sudo xargs -0 chown $newuid
sudo find / -o -gid $oldgid -print0 | sudo xargs -0 chgrp $newgid

You don't really need to create a user with a specific UID as long as changing it's UID right after creation does the right thing. So what we need is to chown the home directory when changing UID for a user. I won't allow choosing UID on user creation since that would bring back the bloat for most users that don't need/understand this option.

2.10.0 has been uploaded to Maverick, waiting for a backport to Lucid.

I find this bug was fixed on 23/4/2010, but I have just been bitten again on 26/11/2010 using a fully updated Lucid LTS.
I know I can work round this using the command line, but ...
I need educating on the process by which bugs are fed back and fixed in Ubuntu releases, especially in LTS releases, where users do want to upgrade until the next LTS comes along. I tried upgrading to 10.10 on one machine to leave more serious bugs behind, but was immediately hit by other regressions. Can anyone point me towards a starting point for my education process? Many would be more enthusiastic about reporting and following up bugs if they could see the results more clearly. I want to be constructive, but I don't know where to start.

Richard: It's fixed in Maverick, but still present in Lucid. See https://wiki.ubuntu.com/Bugs, and especially https://wiki.ubuntu.com/Bugs/Status.

Accepted system-tools-backends into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Any testers of the lucid-proposed package? As this has been in -proposed for a long time already, I'll remove the proposed package soon if there is no feedback. Thank you!

Attempts to verify this fix in -proposed failed using Xubuntu Lucid 10.04, fully updated before enabling -proposed. Both before and after enabling proposed, I added a user, and restarted. I then went to System -> Users and Groups -> Advanced Settings, Advanced tab. I then changed the User ID to 975. I closed Users and Groups and restarted. The User ID changes back to 1001 each time.

I have successfully verified the update in -proposed. With lucid VM and all updates, changing the UID of a user to 999 didn't update /etc/passwd. After installing the update in -proposed, I could successfully change it to 999, at which point the user wasn't available in the GUI anymore.

@Charlie: I'm not sure why you weren't able to reproduce this.

Charlie, thanks for testing! Would you say that from your perspective this is a regression in any way? If not, we could still release it, as it at least fixes the problem for a part of the users?

That's not a regression. In the worst case, nothing changes. But I suspect for some reason Charlie isn't using the version with the fix, since he also said bug 533870 wasn't fixed. What's your version number of system-tools-backends?

This bug was fixed in the package system-tools-backends - 2.9.4-0ubuntu1.1

---------------
system-tools-backends (2.9.4-0ubuntu1.1) lucid-proposed; urgency=low

  * debian/patches/03-lp616682.patch: backport fixes from 2.10.0 to fix
    various issues (LP: #616682):
    - Fix crash on authentication error (LP: #534154)
    - Fix crash due to wrong int size with SelfConfig (LP: #533870)
    - Identify users and groups by login instead of UID (LP: #542183)
    - Major performance improvements when committing groups (LP: #546873)
 -- Marc Deslauriers <email address hidden> Mon, 06 Dec 2010 09:19:18 -0500