Bug 134803 - nfsnobody
Summary: nfsnobody
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libuser
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
 
Reported: 2004-10-06 13:56 UTC by Tim Waugh
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-11 14:03:19 UTC


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

Description Tim Waugh 2004-10-06 13:56:23 UTC
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):
1.2.22-1

How reproducible:
100%

Comment 1 Nils Philippsen 2004-10-06 15:32:10 UTC
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 15:35:03 UTC
libuser-0.52.3-1 (x86_64)

Comment 3 Nils Philippsen 2004-10-06 15:38:38 UTC
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 15:39:57 UTC
s/venture/assume/ -- I need to fix my English...

Comment 5 Miloslav Trmač 2004-10-06 19:00:31 UTC
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 09:14:43 UTC
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 09:38:21 UTC
OK, libuser fault.
Can I get also the output of (grep nfsnobody /etc/group /etc/passwd),
please?


Comment 8 Tim Waugh 2004-10-07 09:49:15 UTC
/etc/group:nfsnobody:x:4294967294:
/etc/passwd:nfsnobody:x:4294967294:4294967294:Anonymous NFS
User:/var/lib/nfs:/sbin/nologin

Comment 9 Nils Philippsen 2004-10-07 09:53:41 UTC
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 10:04:44 UTC
That would be nfs-utils.  But I think it's intentional:

# If UID 65534 (or 4294967294 64bit archs) is unassigned, create user
"nfsnobody"


Comment 11 Nils Philippsen 2004-10-07 10:17:24 UTC
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 10:18:13 UTC
s/on with/on systems with/

Comment 13 Miloslav Trmač 2004-10-07 14:28:15 UTC
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 14:29:51 UTC
(Me either.)

Comment 15 Nils Philippsen 2004-10-07 16:29:34 UTC
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 08:55:52 UTC
Yes, I can't think of any reasonable setup where that would be incorrect.

Comment 17 Nils Philippsen 2004-10-08 10:23:50 UTC
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
User:/var/lib/nfs:/sbin/nologin
nils@gibraltar:~> getent group nfsnobody
nfsnobody:x:4294967294:

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 20:45:16 UTC
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 *
group:nfsnobody:x:4294967294:
passwd:nfsnobody:x:4294967294:4294967294:Anonymous NFS
User:/var/lib/nfs:/sbin/nologin
[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]
[4294967294L]
>>> e[libuser.GIDNUMBER]
[4294967294L]
>>> e = a.lookupGroupByName('nfsnobody')
>>> e[libuser.GIDNUMBER]
[4294967294L]


Comment 19 Nils Philippsen 2004-10-09 01:43:36 UTC
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-09 01:56:12 UTC
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-09 02:38:38 UTC
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 10:38:35 UTC
I hope so.

Comment 23 Tim Waugh 2004-10-10 09:11:05 UTC
system-config-users-1.2.23 fixes it for me. Thanks.

Comment 24 Tim Waugh 2004-10-11 14:03:19 UTC
Closing as RAWHIDE.


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