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.
This is a Fedora only thing since the user name nfsnobody is not used in other distros.
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.
What is the next step? Use that old bz or create new ones?
steved.
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
On Mon, 2018-01-15 at 10:53 -0500, Steve Dickson wrote:
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.
This seems a bit hand-wavy to me. We believe in many layers of security and good practices at every level, yes? Just running things as root and trusting SELinux to restrict their privileges seems like a very airy- fairy way of operating, if that's what you're suggesting.
I'm fairly sure *lots* of daemons in Fedora still drop root privileges early in operation, and this is still widely considered to be good practice. Quite a few have their own unprivileged account to use for this purpose (which is also used to own files they need access to, etc.), but some may still run as 'nobody'. If this could be affected by the Change, it should probably be looked into...
On 15 January 2018 at 15:37, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2018-01-15 at 10:53 -0500, Steve Dickson wrote:
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.
This seems a bit hand-wavy to me. We believe in many layers of security and good practices at every level, yes? Just running things as root and trusting SELinux to restrict their privileges seems like a very airy- fairy way of operating, if that's what you're suggesting.
He was going off of some things from 1999/2000 I remembered (probably poorly). Back then a lot of daemons and tools would run as the user nobody versus running as specific users like apache. In some cases this was hard coded into apps. (what si the default daemon user ? oh nobody). The other problem was that in NFS heavy environments this was a security problem because if you broke out of named, you had the same rights as every other nobody app.. which some NFS servers would allow to read access (if not write access).
So having nobody not running as the nfs nobody was a security measure to stop bind/httpd servers from serving /etc/shadow on a diskless environment or other weird items. The nfs nobody wasn't listed in /etc/passwd for a long time because it was considered a reserved not used port. Until bug reports built up about places using it or getting confused because the ldap nobody was 6553x but the 99 was nobody. So nfsnobody was put in to fix that problem.
So he is going over why nfsnobody and nobody were put into the system and why they are different in Red Hat Linux versus debian/etc. Those decisions were made before selinux so the original reasons may not make sense.
I'm fairly sure *lots* of daemons in Fedora still drop root privileges early in operation, and this is still widely considered to be good practice. Quite a few have their own unprivileged account to use for this purpose (which is also used to own files they need access to, etc.), but some may still run as 'nobody'. If this could be affected by the Change, it should probably be looked into... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Mon, Jan 15, 2018 at 3:37 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2018-01-15 at 10:53 -0500, Steve Dickson wrote:
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.
This seems a bit hand-wavy to me. We believe in many layers of security and good practices at every level, yes? Just running things as root and trusting SELinux to restrict their privileges seems like a very airy- fairy way of operating, if that's what you're suggesting.
This is especially true because in development environments, it is a very common practice to disable SELinux or set it to "permissive" and only activate and tune it after development is complete. I've particularly seen this in MacBook using Java developers: their OS does not support SELinux, and they only bother with SELinux, if they bother, with the simplest possible rules to get their project working. SELinux can be useful, but can fail outright, even in security sensitive environments, for just these reasons.
I'm fairly sure *lots* of daemons in Fedora still drop root privileges early in operation, and this is still widely considered to be good practice. Quite a few have their own unprivileged account to use for this purpose (which is also used to own files they need access to, etc.), but some may still run as 'nobody'. If this could be affected by the Change, it should probably be looked into...
This seems to be good reasoning. The idea that "nobody" might be used by multiple daemons is.... well, it's troubling.
-
Adam Williamson -
Nico Kadel-Garcia -
Stephen John Smoogen -
Steve Dickson -
Zbigniew Jędrzejewski-Szmek