Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 134803 - nfsnobody
Product: Fedora
Classification: Fedora
Component: libuser (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
Depends On:
Blocks: FC3Target
  Show dependency treegraph
Reported: 2004-10-06 09:56 EDT by Tim Waugh
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-11 10:03:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Log entity names and numbers (1.08 KB, patch)
2004-10-06 15:00 EDT, Miloslav Trmač
no flags Details | Diff

  None (edit)
Description Tim Waugh 2004-10-06 09:56:23 EDT
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):

How reproducible:
Comment 1 Nils Philippsen 2004-10-06 11:32:10 EDT
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".
Comment 2 Tim Waugh 2004-10-06 11:35:03 EDT
libuser-0.52.3-1 (x86_64)
Comment 3 Nils Philippsen 2004-10-06 11:38:38 EDT
Then I venture this is a libuser bug which manifests only on x86_64 or
maybe other 64bit platforms. Miloslav?
Comment 4 Nils Philippsen 2004-10-06 11:39:57 EDT
s/venture/assume/ -- I need to fix my English...
Comment 5 Miloslav Trmač 2004-10-06 15:00:31 EDT
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?
Comment 6 Tim Waugh 2004-10-07 05:14:43 EDT
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
Comment 7 Miloslav Trmač 2004-10-07 05:38:21 EDT
OK, libuser fault.
Can I get also the output of (grep nfsnobody /etc/group /etc/passwd),
Comment 8 Tim Waugh 2004-10-07 05:49:15 EDT
/etc/passwd:nfsnobody:x:4294967294:4294967294:Anonymous NFS
Comment 9 Nils Philippsen 2004-10-07 05:53:41 EDT
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.
Comment 10 Tim Waugh 2004-10-07 06:04:44 EDT
That would be nfs-utils.  But I think it's intentional:

# If UID 65534 (or 4294967294 64bit archs) is unassigned, create user
Comment 11 Nils Philippsen 2004-10-07 06:17:24 EDT
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?
Comment 12 Nils Philippsen 2004-10-07 06:18:13 EDT
s/on with/on systems with/
Comment 13 Miloslav Trmač 2004-10-07 10:28:15 EDT
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.
Comment 14 Tim Waugh 2004-10-07 10:29:51 EDT
(Me either.)
Comment 15 Nils Philippsen 2004-10-07 12:29:34 EDT
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?
Comment 16 Miloslav Trmač 2004-10-08 04:55:52 EDT
Yes, I can't think of any reasonable setup where that would be incorrect.
Comment 17 Nils Philippsen 2004-10-08 06:23:50 EDT
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 [74]
add group nfsnobody [2147483647]
add group apache [48]

This is with:

nils@gibraltar:~> getent passwd nfsnobody
nfsnobody:x:4294967294:4294967294:Anonymous NFS
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.
Comment 18 Miloslav Trmač 2004-10-08 16:45:16 EDT
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 *
passwd:nfsnobody:x:4294967294:4294967294:Anonymous NFS
[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[libuser.UIDNUMBER]
>>> e[libuser.GIDNUMBER]
>>> e = a.lookupGroupByName('nfsnobody')
>>> e[libuser.GIDNUMBER]
Comment 19 Nils Philippsen 2004-10-08 21:43:36 EDT
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).
Comment 20 Miloslav Trmač 2004-10-08 21:56:12 EDT
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.
Comment 21 Nils Philippsen 2004-10-08 22:38:38 EDT
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 ()").
Comment 22 Miloslav Trmač 2004-10-09 06:38:35 EDT
I hope so.
Comment 23 Tim Waugh 2004-10-10 05:11:05 EDT
system-config-users-1.2.23 fixes it for me. Thanks.
Comment 24 Tim Waugh 2004-10-11 10:03:19 EDT
Closing as RAWHIDE.

Note You need to log in before you can comment on or make changes to this bug.