On Mon, Jan 15, 2018 at 10:53:32AM -0500, Steve Dickson wrote: > Hello, > > In summary: Legacy application that expect the 99 uid or the > 'nfsnobody' user name will break, but from an NFS protocol > aspect I think we are fine since the same value is going > over the wire. Cool, thanks. > This is a Fedora only thing since the user name nfsnobody is > not used in other distros. I grepped for nfsnobody, and I was surprised to find a string referenced in a few places: /lib/dracut/modules.d/95nfs/module-setup.sh /bin/hyperkube /bin/kube-controller-manager /bin/kube-scheduler /bin/flatpak /bin/kube-proxy /bin/kubelet /bin/lslogins /bin/kubectl /var/lib/rpm/Packages /var/cache/dnf/fedora-filenames.solvx (plus so files under /lib/.build-id, but those are OK.) I'll need to go over those and verify what are they using the name for. > The Details: > On 01/13/2018 06:18 PM, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Jan 13, 2018 at 10:18:14AM -0500, Steve Dickson wrote: > >> On 01/13/2018 08:50 AM, Steve Dickson wrote: > >>> So I guess the next question is what the current > >>> nobody id (25) used for and why does it exist? > >> > >> Doing some research on this back in Aug 2001 > >> nfsnobody was added to nfs-utils for the reasons stated in > >> https://bugzilla.redhat.com/show_bug.cgi?id=22685 > > That bug is rh-private. Copying the important bit below: > > > > Bob Matthews 2001-08-24 11:50:09 EDT > >> Hackish fix is in RAWHIDE. I'm marking this closed DEFERRED until a real > >> fix comes down the pipe from the nfs-utils maintaine> > > There weren't any reasons really, except the need to quickly provide a > > name for 65534 and 'nobody' was already used for 99 and there wasn't > > time to do the renaming properly. I think it is fitting that we finish > > the process with a proper fix to change the bug status to RESOLVED for > > the 17th anniversary. > Googling 'linux nobody uid' it appears nobody is a uid used by apps > that don't want to run as root. In case they got hacked the would > not have root privileges, but with SElinux around I think that > problem has been solve. > > But legacy apps that do a chown(3) call to uid 99 will break. > > > > > So... I was away from this thread for two days, and there was a lot of > > back and forth, but not too much new information. For this change to > > be implemented properly, input from NFS maintainers is very important. > > Steve, please, consider if there are any changes needed in nfs-utils > > to support the nfsnobody→nobody name change, apart from what is > > described in the Change page. If some additional info or steps need to > > be added, please say so. > Again, the biggest issue I see is backwards compatibility with NFS > users expecting nfsnobody to exist. Protocol wise I think we are > fine since the value is going over the wire will not change. > > Is it wrong to expect a uid or user name to exist across releases? > In the Fedora world... probably not... but in the enterprise > world... it could be. Only time will tell. > > > The change has to made in two packages nfs-utils and setup > with the bigger change in setup. > > From packaging stand point I think it would be good for > nfs-utils to get out of the user/group creation business, > so once the changes are made to setup, I'll just add a > dependency to the setup and no longer create users > and groups. > > Here is what has to change: > From: > nobody:x:99:99:Nobody:/:/sbin/nologin > nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin > nobody:x:99: > nfsnobody:x:65534: > > To: > nobody:x:65534:65534:Nobody:/:/sbin/nologin > nobody:x:65534 > > With a few other nits to be cleaned up in setup. > > Since we are here... does it make sense to update nobody > home directory to something like: > > nobody:x:65534:65534:Nobody:/root:/sbin/nologin > > Or give it its own home dir: > > nobody:x:65534:65534:Nobody:/nobody:/sbin/nologin > > Obviously that is up to the maintainers of setup. I think "/" is the proper homedir. Anything else is either wrong or doesn't exist. > What is the next step? Use that old bz or create > new ones? I think the proper way of doing this in the new scheme is PR requests in pagure. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
