[users-admin] Changing UID doesn't work

Bug #542183 reported by fossfreedom
84
This bug affects 13 people
Affects Status Importance Assigned to Milestone
system-tools-backends
Fix Released
Undecided
Unassigned
system-tools-backends (Ubuntu)
Fix Released
Medium
Unassigned
Lucid
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: gnome-system-tools

in karmic and previous versions of ubuntu, you could hide users from the GDM by changing their User ID (system -administrator - users & groups - advanced settings) to a number below 1000.

In lucid, you can change the number, but next time you reopen the advanced settings window, the number resets itself.

if you sudo usermod -u 999 <user> then the user is correctly hidden from the GDM

ProblemType: Bug
Architecture: i386
Date: Fri Mar 19 20:34:00 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100224.1)
Package: gnome-system-tools 2.29.91-0ubuntu2
ProcEnviron:
 PATH=(custom, user)
 LANG=C
 SHELL=/bin/bash
SourcePackage: gnome-system-tools
Uname: Linux 2.6.31-02063112-generic i686

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

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.

summary: - regression cannot hide users from gdm
+ [users-admin] Changing UID doesn't work
affects: gnome-system-tools (Ubuntu) → system-tools-backends (Ubuntu)
Changed in system-tools-backends (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in system-tools-backends:
status: New → Fix Committed
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Fixed with 2.10.0, not yet in Lucid though.

Changed in system-tools-backends:
status: Fix Committed → Fix Released
Revision history for this message
ceg (ceg) wrote :

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?

Revision history for this message
ceg (ceg) wrote :

Is gst using usermod? Its manpage says:

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

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

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

Revision history for this message
Simon (simsiem) wrote :

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

Revision history for this message
Peter Valdemar Mørch (pmorch) wrote :

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.

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

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.

Revision history for this message
Peter Valdemar Mørch (pmorch) wrote :

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

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

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.

Revision history for this message
Peter Valdemar Mørch (pmorch) wrote :

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

Revision history for this message
Peter Valdemar Mørch (pmorch) wrote :

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

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

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.

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

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

Changed in system-tools-backends (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Richard M Smith (richard-featplus-com) wrote :

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.

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

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.

Changed in system-tools-backends (Ubuntu Lucid):
status: New → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

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!

tags: added: verification-needed
Revision history for this message
Martin Pitt (pitti) wrote :

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!

tags: added: verification-failed
removed: verification-needed
Revision history for this message
Charlie Kravetz (charlie-tca) wrote :

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.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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.

tags: added: verification-done
removed: verification-failed
Revision history for this message
Martin Pitt (pitti) wrote :

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?

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

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?

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in system-tools-backends (Ubuntu Lucid):
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