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%
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".
libuser-0.52.3-1 (x86_64)
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), please?
/etc/group:nfsnobody:x:4294967294: /etc/passwd:nfsnobody:x:4294967294:4294967294:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
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 "nfsnobody"
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.
(Me either.)
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 [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.
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]
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.