problem with big uids in "Users and Groups" tool

[Aaro Koskinen]

Description: Ubuntu 8.04.1, Ubuntu 8.10
Release: 8.04, 8.10

System > Administration > Users and Groups has problems with uids with apparently more than 16 bits:

1) Add e.g. a user "test" and set the uid to 99999. The uid will be silently replaced with 65535, and if you still press OK and check the properties of the newly added user's uid will be shown as 0.

2) For some reason the user won't be actually created, but a group is. No error messages are given.

3) If you create a similar uid from shell (e.g. adduser -uid 99999 test) and then check it with the GUI the uid is shown as 0.

4) If you try to delete the user created in (3) with "Users and Groups" it thinks it's an admin account and refuses to delete it.

[Dan Trevino (dantrevino)]

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 system-tools-backends.
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.

[Dan Trevino (dantrevino)]

I can confirm the behavior as described above for 8.04 and 8.10.

[Milan Bouchet-Valat (nalimilan)]

I think 65535 is the maximum ID. The spin button should refuse higher values.

[Milan Bouchet-Valat (nalimilan)]

Fixed upstream. Should be available in Karmic when 2.27.92 is released.

The problem was that the maximum UID/GID for Ubuntu is 60000, or at least it is that value which is used by the backends. The 65535 limit was hardcoded, hence you could go beyond the limit, and the tool tried to create invalid users, rejected by the backends. Now, we may wonder whether 60000 is an accurate maximum for Ubuntu, but that's easy to solve, and we now do things The Right Way.

[Aaro Koskinen (aaro-koskinen)]

The 60000 limit sounds too low.

[Milan Bouchet-Valat (nalimilan)]

Not my problem! ;-)

More seriously, I've checked that we're doing our work correctly, and it appears that this figure comes from /etc/login.defs, which is shipped by the package 'login'. So, if you think that's an issue, please report a bug against that package.

[Kari Hautio (khautio)]

Well, I would recommend checking the facts first. What there is in login.defs is following (read the comment).

<cut>
#
# Min/max values for automatic uid selection in useradd
#
UID_MIN 1000
UID_MAX 60000
<cut>

I.e. the automatic selection of the new UID should use these values, but it does not define any limits for manual selection.

The actual UID is a 32bit value (it used to be 16bits long ago). Also in many corporate environments large (>100000) UID values are used to create a very large continuous UID space (basically to avoid the nobody at 65534).

[Milan Bouchet-Valat (nalimilan)]

You got me. ;-) I should have read that comment.

You seem to master how all these settings work. So you think it's safe to allow people to choose UIDs up to MAX_INT? I'll see what I can do, but that will require a new version of the backends accepting that before the GUI can do that, else we're going to suffer from the same bug as before.

[Milan Bouchet-Valat (nalimilan)]

Actually I have committed a fix in August that allows you to choose a UID/GID up to MAX_UINT32, because we use this type in the D-BUS spec of the backends. So that should be good for what you asked. See
http://git.gnome.org/cgit/gnome-system-tools/commit/?id=7469b0c617021f9b9b9ca1dcd3386e9379bb82ec

So I'm marking it as fixed, please confirm that I did not miss a hidden problem. Thanks!

[Kari Hautio (khautio)]

Tested with this up to date Karmic:

The behavior is a little different but it still refuses to create a user with UID of 100000.

Following warning is outputted:

(users-admin:1866): Glib-GObject-WARNING **: value "100000" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'

There is also additional annoyance as the group for the user is created but the user get silently lost, this makes further attempts to create user with same name fail with "Group "xxx" already exits / Plese choose a different name."

Creating a group with gid=100000 fails also

(users-admin:2043): Glib-GObject-WARNING **: value "100000" of type 'gint' is invalid or out of range for property 'gid' of type 'gint'

Tested with: gnome-system-tools 2.28.1-0ubuntu2 on amd64

[Milan Bouchet-Valat (nalimilan)]

Again... Tricky issue. Considering the precise bug you found, it comes from the fact that the max [GU]ID was statically defined as 65,535. I'll fix that easily, but I lack a generic way of detecting the actual system maximum for gid_t. I guess I've found a hack that will work, though. That will be for the next release. For now, stay with IDs below 65,535 - anyway, defaults in /etc/login.defs are 60,000. Do you really need this, or is that just a question of principles? ;-)

There's also a broader issue: the D-Bus protocol uses a 32-byte int for [UG]IDs, because we use -1 to mean "none" when talking about main group. So we cannot allow values above G_MAXINT32, which is 2,147,483,647. That can be considered enough, though - but platforms often allow to reach G_MAXUINT32, which is twice this limit, and could go further. This needs a change in the protocol.

[Milan Bouchet-Valat (nalimilan)]

OK, I've just committed a fix that allows IDs to be handled correctly as long as they don't go beyond G_MAXINT32 when the system supports it, which means on Ubuntu you can go up to 2,147,483,647. I guess that's enough for most people, but I'll see if we can guarantee we support the full range for 32-bit IDs in a later release.

[Kari Hautio (khautio)]

Hi, had a quick look on your commit and you really should not use pow() from math.h but use shift left i.e. "<<"

#include<math.h>
#define OOBS_MAX_UID MIN (G_MAXINT32, pow (2, 8 * sizeof (uid_t) - 1))
#define OOBS_MAX_GID MIN (G_MAXINT32, pow (2, 8 * sizeof (gid_t) - 1))

is identical to this which avoids doing floating point

#define OOBS_MAX_UID MIN (G_MAXINT32, 1L<<(8 * sizeof (uid_t) - 1))
#define OOBS_MAX_GID MIN (G_MAXINT32, 1L<<(8 * sizeof (gid_t) - 1))

[Milan Bouchet-Valat (nalimilan)]

Are people actually watching liboobs development?! ;-)

I've tried using << before, but I was getting strange results because when converting the constant value to signed int, something was going wrong and I was getting -GMAX_INT32. I've tried again with your solution, and that does not work either. Though, this one does, despite being pretty ugly:
((guint32) (1 << (8 * sizeof (uid_t) - 1)) - 1))

So I guess I'm going to use that one. What was the 1L supposed to fix?

Though, note that recent gcc versions detect pow() using constant (esp. integers), and replace them with their actual result, so no runtime overhead is happening ATM, and floating point are not even used.

[Milan Bouchet-Valat (nalimilan)]

All of this is fixed with the System Tools Backends 2.9.0 and liboobs 2.29.2.

[Milan Bouchet-Valat (nalimilan)]

Fixed with the gnome-system-tools 2.29.3 now in Lucid.