Red Hat Bugzilla – Bug 134803
Last modified: 2007-11-30 17:10:51 EST
Description of problem:
nfsnobody is shown as a user in system-config-users. This system user
should be hidden.
It shows user ID -2 and Primary Group 4294967294.
Version-Release number of selected component (if applicable):
Which libuser version do you use? I ask because I use the same version
of s-c-users and libuser-0.52.3-1 and here it gets filtered okay and
the primary group is "nfsnobody".
Then I venture this is a libuser bug which manifests only on x86_64 or
maybe other 64bit platforms. Miloslav?
s/venture/assume/ -- I need to fix my English...
Created attachment 104852 [details]
Log entity names and numbers
I can't reproduce it in thor buildroot with libuser-0.52.3-1
and current CVS s-c-users. Reading the code of both libuser
and s-c-users didn't suggest anything either.
Tim, could you please apply the attached patch to s-c-users
and attach the stdout?
Adding user 'operator', uid 11L
Adding user 'rpm', uid 37L
Adding user 'shutdown', uid 6L
Adding user 'mailnull', uid 47L
Adding user 'nfsnobody', uid 4294967294L
Adding user 'bin', uid 1L
Adding user 'lp', uid 4L
Adding user 'games', uid 12L
Adding user 'gdm', uid 42L
Adding user 'halt', uid 7L
Adding user 'netdump', uid 34L
Adding user 'nscd', uid 28L
Adding user 'pcap', uid 77L
Adding user 'gopher', uid 13L
Adding user 'sshd', uid 74L
Adding user 'mail', uid 8L
Adding user 'adm', uid 3L
Adding user 'rpc', uid 32L
Adding user 'ftp', uid 14L
Adding user 'ntp', uid 38L
Adding user 'news', uid 9L
Adding user 'dbus', uid 81L
Adding user 'haldaemon', uid 68L
Adding user 'smmsp', uid 51L
Adding user 'nobody', uid 99L
Adding user 'vcsa', uid 69L
Adding user 'rpcuser', uid 29L
Adding user 'uucp', uid 10L
Adding user 'tim', uid 500L
Adding user 'sync', uid 5L
Adding user 'daemon', uid 2L
Adding user 'root', uid 0L
Adding user 'xfs', uid 43L
Adding group 'tty', gid 5L
Adding group 'users', gid 100L
Adding group 'tim', gid 500L
Adding group 'root', gid 0L
Adding group 'slocate', gid 21L
Adding group 'mail', gid 12L
Adding group 'dbus', gid 81L
Adding group 'xfs', gid 43L
Adding group 'disk', gid 6L
Adding group 'haldaemon', gid 68L
Adding group 'bin', gid 1L
Adding group 'floppy', gid 19L
Adding group 'news', gid 13L
Adding group 'rpc', gid 32L
Adding group 'lp', gid 7L
Adding group 'gopher', gid 30L
Adding group 'mailnull', gid 47L
Adding group 'gdm', gid 42L
Adding group 'ftp', gid 50L
Adding group 'netdump', gid 34L
Adding group 'uucp', gid 14L
Adding group 'dip', gid 40L
Adding group 'pcap', gid 77L
Adding group 'smmsp', gid 51L
Adding group 'mem', gid 8L
Adding group 'rpm', gid 37L
Adding group 'nfsnobody', gid 4294967294L
Adding group 'sys', gid 3L
Adding group 'daemon', gid 2L
Adding group 'man', gid 15L
Adding group 'vcsa', gid 69L
Adding group 'sshd', gid 74L
Adding group 'kmem', gid 9L
Adding group 'lock', gid 54L
Adding group 'ntp', gid 38L
Adding group 'nobody', gid 99L
Adding group 'utmp', gid 22L
Adding group 'games', gid 20L
Adding group 'adm', gid 4L
Adding group 'wheel', gid 10L
Adding group 'nscd', gid 28L
Adding group 'rpcuser', gid 29L
OK, libuser fault.
Can I get also the output of (grep nfsnobody /etc/group /etc/passwd),
Seems like a bug in whatever package added the nfsnobody user (just
stating the obvious). Still can't figure out why that would happen though.
That would be nfs-utils. But I think it's intentional:
# If UID 65534 (or 4294967294 64bit archs) is unassigned, create user
So in the end it's mine anyway. So there is likely something that
treats the uid as signed when it should be unsigned and it should
rather check against 4294967294 on with 32bit UIDs. Is there a
reliable way to check whether we have 16bit or 32bit UIDs?
s/on with/on systems with/
We have "32-bit UIDs" on i386 too (uid_t is unsigned int< at least
in user-space). Unfortunately I can't access bug 123900, which seems
to be the reason why (only recent) nfs-utils use 4294967294.
I can't access that bug as well... Anyway I think that we can safely
filter out users that have name=="nfsnobody" and (uid==65534 or uid==
4294967294), do you agree?
Yes, I can't think of any reasonable setup where that would be incorrect.
Unfortunately on x86, libuser returns ints instead of longs which seem
to wrap, see here (with some debugging statements):
add user mail [8/12]
add user nfsnobody [2147483647/2147483647]
add user pcap [77/77]
add group sshd 
add group nfsnobody 
add group apache 
This is with:
nils@gibraltar:~> getent passwd nfsnobody
nils@gibraltar:~> getent group nfsnobody
Miloslav, can you please fix this and bump the bug back to me so that
I can see whether my fixes actually work? Thanks.
That is bug #124967, which will be hard to fix without
completely breaking the (C-language) ABI, if it is possible
at all. I don't think delaying the s-c-users change for
bug 124967 is practical.
If it is of any help, here is a script of a thor testing session:
[root@thor mitr]# grep nfsnobody *
[root@thor mitr]# LIBUSER_CONF=/tmp/mitr/libuser.conf python
Python 2.3.4 (#1, Aug 31 2004, 10:17:22)
[GCC 3.4.1 20040815 (Red Hat 3.4.1-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import libuser
>>> a = libuser.admin()
>>> e = a.lookupUserByName('nfsnobody')
>>> e = a.lookupGroupByName('nfsnobody')
system-config-users-1.2.23 has fixes for this problem, can you please
try it out on 64bit? Still we should see how we could hack libuser to
provide long uids and gids, from looking at the headers all structures
and functions seem opaque enough to me that we should be able to pull
that off within the existing ABI (correct me if/where I'm wrong).
The trouble is that there is also an "implied ABI": all GValues
are either strings or longs. This is enforced using asserts
both inside libuser (all over the place) and usermode (libuser
user). "long" wraps to negative values for about half of the
valid id_t space.
Something must be done about it, I just can't give any realistic
estimate when it will be fixed.
Might sound a bit selfish, but maybe we could ensure that the python
interface returns unsigned, positive values. Do you think this is
doable? I could also imagine some hack like toggling a new "implied
ABI" which returns ulongs ("libuser_enable_large_ugids ()").
I hope so.
system-config-users-1.2.23 fixes it for me. Thanks.
Closing as RAWHIDE.