Re: RFC: Fixing the "nobody" user?
On Mon, Jul 18, 2016 at 03:59:09PM +0200, Ondřej Vašík wrote: > Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200: > > Heya! > > > > I'd like to start a discussion regarding the "nobody" user on Fedora, > > and propose that we change its definition sooner or later. I am not > > proposing a feature according to the feature process for this yet, but > > my hope is that these discussions will lead to one eventually. > > Thanks for starting the discussion on Fedora devel - as there already > was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended > up closed NOTABUG - as the nfs-utils maintainer is concerned about such > change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and > most of commenters (moved across several components) recommended "not a > bug" resolution. That was me. (I'm not the nfs-utils maintainer, though.) I honestly didn't think about it much beyond: there might be some risk to the change, so it needs some justification. So, trying to think it through some more from an NFS point of view: For authentication, rpc uses either numeric ID's or kerberos names. For referring to principals in file owners, groups, or ACLs, NFSv2/v3 uses numeric ID's, NFSv4 may use string names instead in some cases. So in the NFSv4 case you could end up with a read-modify-write of an ACL resulting in on-disk references to uid 99 turning into 65534's. That can happen in the local case too if, say, you're using a commandline utility that uses names, and you map 99 and 65534 both to "nobody" and "nobody" back to 65534. NFS users can already see that sort of behavior in mixed-distro environments. Anyway, I don't know. It'd certainly be nice to see the current situation cleaned up. I don't feel like I understand what might break on transition. --b. > > I agree with containers and user namespaces, overflow uid named > "nfsnobody" confuses users. But is there really some good and > non-disruptive solution? e.g. Overflow id can be changed to different > than (uint_16_t) -2, but it is the right way? > > > Most distributions (in particular Debian/Ubuntu-based ones) map the > > user "nobody" to UID 65534. I think we should change Fedora to do the > > same. Background: > > > > On Linux two UIDs are special: that's UID 0 for root, which is the > > privileged user we all know. And then there's UID 65534 > > (i.e. (uint16_t) -2), which is less well known. The Linux kernel calls > > it the "overflow" UID. It has four purposes: > > > > 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs > >only supports 16bit UIDs, but a 32bit UID is passed to it. > > > > 2. it's used by the kernel's user namespacing as a the internal UID > >that external UIDs are mapped to that don't have any local mapping. > > > > 3. It's used by NFS for all user IDs that cannot be mapped locally if > >UID mapping is enabled. > > > > 4. One upon a time some system daemons chose to run as the "nobody" > >user, instead of a proper system user of their own. But this is > >universally frowned upon, and isn't done on any current systems > >afaics. In fact, to my knowledge Fedora even prohibits this > >explicitly in its policy (?). > > > > The uses 1-3 are relevant today, use 4 is clearly obsolete > > afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something > > that cannot be mapped properly is mapped to". > > > > On Fedora, we currently have a "nobody" user that is defined to UID > > 99. It's defined unconditionally like this. To my knowledge there's no > > actual use of this user at all in Fedora however. The UID 65514 > > carries no name by default on Fedora, but as soon as you install the > > NFS utils it gets mapped to the "nfsnobody" user name, misleadingly > > indicating that it would be used only by NFS even though it's a much > > more general concept. I figure the NFS guys adopted the name > > "nfsnobody" for this, simply because "nobody" was already taken by UID > > 99 on Fedora, unlike on other distributions. > > It is really a historical reason. I don't think there was common > agreement at the time when 99 for nobody was selected (at least several > different approaches were in place these days). > > > In the context of user namespacing the UID 65534 appears a lot more > > often as owner of various files. For example, if you turn on user > > namespacing in typical container managers you'll notice that a ton of > > files in /proc will then be owned by this user. Very confusingly, in a > > container that includes the NFS utils all those files actually show up > > as "nfsnobody"-owned now, even though there's no relation to NFS at all > > for them. > > > > I'd like to propose that we clean this up, and just make Fedora work > > like all other distributions. After all the reason of having this > > special UID in the first place is to sidestep mapping problems between > > different UID "realms". Hence I think it would be wise to at least >
Re: RFC: Fixing the "nobody" user?
Oron Peled wrote: > On יום שלישי, 19 ביולי 2016 15:23:25 IDT Matthew Miller wrote: > > ... > > I remember when this came up before but can't find it now. I think it > > was changed to 99 when UIDs went to 32 bit and it suddenly started > > being 65535 on some systems and 4294967295 on others. * I was trying to > > figure out why 99 was eventually chosen, but can't find it now. > > I believe the uid 99 come from trying not to overlap regular users. > Back then (end of 90's), regular users uid's were: > * On old RedHat Linux >= 500 > * On some other Linux systems >= 1000 > * On many legacy Unices >= 100 (except on Irix >= 1000) > > It was very common to have NFS mounted /home across all servers (with > different *NIX vendors/versions). > So '99' was the "last" uid that was assured not to collide with uid's of > regular users on NFS. Solaris and IRIX used to have 60001 as nobody, *and* either -2 or 65534 as nobody, either under the same name (!!!) or some alternative similar to nfsnobody. I don't think you want to assume that code thinks the two users are really identical in practice or that it's safe to merge them, though. -- Steve -- Steven BonnevilleTechnical Curriculum Architect Red Hat | Red Hat Training Phone: +1-612-638-0507 gpg: 1024D/221D06FF 68B1 3E66 A351 6485 B9AF 24D8 3DF5 B50B 221D 06FF -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On יום שלישי, 19 ביולי 2016 15:23:25 IDT Matthew Miller wrote: > ... > I remember when this came up before but can't find it now. I think it > was changed to 99 when UIDs went to 32 bit and it suddenly started > being 65535 on some systems and 4294967295 on others. * I was trying to > figure out why 99 was eventually chosen, but can't find it now. I believe the uid 99 come from trying not to overlap regular users. Back then (end of 90's), regular users uid's were: * On old RedHat Linux >= 500 * On some other Linux systems >= 1000 * On many legacy Unices >= 100 (except on Irix >= 1000) It was very common to have NFS mounted /home across all servers (with different *NIX vendors/versions). So '99' was the "last" uid that was assured not to collide with uid's of regular users on NFS. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron No, You Can't Have My Rights, I'm Still Using Them -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On Mon, Jul 18, 2016 at 10:18:49AM -0400, Stephen John Smoogen wrote: > > I'd like to start a discussion regarding the "nobody" user on Fedora, > > and propose that we change its definition sooner or later. I am not > > proposing a feature according to the feature process for this yet, but > > my hope is that these discussions will lead to one eventually. > I am not against this proposal. It has been tried at least once before > in the past but those failed due to a lot of programs secretly relying > on the seperate uids and not a lot of people being able to fix it. > > I am not 100% certain that it was mostly 99 due to issues with various > network authentication systems from long ago. (ypbind/ldap/etc) where I remember when this came up before but can't find it now. I think it was changed to 99 when UIDs went to 32 bit and it suddenly started being 65535 on some systems and 4294967295 on others. * I was trying to figure out why 99 was eventually chosen, but can't find it now. In any case, the regularization makes sense to me. * At $formeruniversity, we had someone who was trying to back up /var/log without any special handling for sparse files and they suddenly got very surprised and upset when lastlog became "gigantic". Ah, good times. -- Matthew MillerFedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On Tue, 2016-07-19 at 07:39 -0400, Nico Kadel-Garcia wrote: > Like I said, I'm thinking of "rsync", "tar", and "star". Also, > people do some interesting scripting to detect things like failed > NFS configurations. I'm not saying that's a blocker, but shifting it > to overlap with the current "nfsnobody" is likely to break some > people's tools in the field, especially if they run the latest Fedora > alongside RHEL, CentOS, or previous Fedora releases. The breakage for some will be un-breakage for someone else, and being consistent with the kernel point of view and other distributions, in this case, is more important IMO. Simo. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On Mon, 2016-07-18 at 14:39 +0200, Lennart Poettering wrote: > Heya! > > I'd like to start a discussion regarding the "nobody" user on Fedora, > and propose that we change its definition sooner or later. I am not > proposing a feature according to the feature process for this yet, > but > my hope is that these discussions will lead to one eventually. > > Most distributions (in particular Debian/Ubuntu-based ones) map the > user "nobody" to UID 65534. I think we should change Fedora to do the > same. Background: > > On Linux two UIDs are special: that's UID 0 for root, which is the > privileged user we all know. And then there's UID 65534 > (i.e. (uint16_t) -2), which is less well known. The Linux kernel > calls > it the "overflow" UID. It has four purposes: > > 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs > only supports 16bit UIDs, but a 32bit UID is passed to it. > > 2. it's used by the kernel's user namespacing as a the internal UID > that external UIDs are mapped to that don't have any local > mapping. > > 3. It's used by NFS for all user IDs that cannot be mapped locally if > UID mapping is enabled. > > 4. One upon a time some system daemons chose to run as the "nobody" > user, instead of a proper system user of their own. But this is > universally frowned upon, and isn't done on any current systems > afaics. In fact, to my knowledge Fedora even prohibits this > explicitly in its policy (?). > > The uses 1-3 are relevant today, use 4 is clearly obsolete > afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something > that cannot be mapped properly is mapped to". > > On Fedora, we currently have a "nobody" user that is defined to UID > 99. It's defined unconditionally like this. To my knowledge there's > no > actual use of this user at all in Fedora however. The UID 65514 > carries no name by default on Fedora, but as soon as you install the > NFS utils it gets mapped to the "nfsnobody" user name, misleadingly > indicating that it would be used only by NFS even though it's a much > more general concept. I figure the NFS guys adopted the name > "nfsnobody" for this, simply because "nobody" was already taken by > UID > 99 on Fedora, unlike on other distributions. > > In the context of user namespacing the UID 65534 appears a lot more > often as owner of various files. For example, if you turn on user > namespacing in typical container managers you'll notice that a ton of > files in /proc will then be owned by this user. Very confusingly, in > a > container that includes the NFS utils all those files actually show > up > as "nfsnobody"-owned now, even though there's no relation to NFS at > all > for them. > > I'd like to propose that we clean this up, and just make Fedora work > like all other distributions. After all the reason of having this > special UID in the first place is to sidestep mapping problems > between > different UID "realms". Hence I think it would be wise to at least > make the name of this very special UID somewhat more stable and > well-defined between distributions. > > I think this is of particular relevance as Debian/Ubuntu-based > container images tend to be substantially more popular than > Fedora-based ones, and hence I think we should try to unify at least > the names and semantics of the two special UIDs all distros have, to > minimize mapping problems and making user interaction in containers a > bit more friendly. > > You might ask of course, why Fedora should change to adopt > Debian's/Ubuntu's definition, instead of conversely making them adopt > Fedora's definition? Well, that's simple: Debian's definition makes a > lot more sense than Fedora's. And nothing we ship actually makes use > of FEdora's definition afaics, and we currently carry a workaround > called "nfsnobody" in some cases to avoid having to fix this > properly. > > Another option would be to define an entirely new user name for > 65534, > for example "void" or so. But quite frankly, that sounds like a > pointless bikeshedding excercise, and creates even more confusion, > balkanization and political hassles if you'd try to convince other > distros to adopt the same scheme too. > > Hence, let's go for "nobody == 65534" on Fedora too! And let's unify > the various dsitributions a tiny bit more, on this specific aspect. > > How could a transition look like? I figure new installs should get > "nobody" defined to 65534. Old installs should keep the old > definitions in place instead. The NFS packages should be updated to > not create the "nfsnobody" user if there's already another user > mapped > to 65534 (maybe it already does that?). Of course it's not pretty if > old and new systems use different definitions for this user, but I > think it's not too much of a real-life issue, as most code that > refers > to this group already does so by UID instead of name, simply because > the name is not stable across distributions. > > Opinions? +1,
Re: RFC: Fixing the "nobody" user?
On Mon, Jul 18, 2016 at 8:39 AM, Lennart Poetteringwrote: > On Fedora, we currently have a "nobody" user that is defined to UID > 99. It's defined unconditionally like this. To my knowledge there's no > actual use of this user at all in Fedora however. The UID 65514 > carries no name by default on Fedora, but as soon as you install the > NFS utils it gets mapped to the "nfsnobody" user name, misleadingly > indicating that it would be used only by NFS even though it's a much > more general concept. I figure the NFS guys adopted the name > "nfsnobody" for this, simply because "nobody" was already taken by UID > 99 on Fedora, unlike on other distributions. At first glance it makes some sense. 2^32-2 doesn't force it into 64-bit space, it's tested on other operating systems, I'm concerned that overlapping "nobody" with the working "nfsnobody" is going to break tools. I'm also cncerned that it will change behavior for "tar", "rsync", "star", and other programs that can be configured to store and extract usernames *or* uids, or a mix of both. > In the context of user namespacing the UID 65534 appears a lot more > often as owner of various files. For example, if you turn on user > namespacing in typical container managers you'll notice that a ton of > files in /proc will then be owned by this user. Very confusingly, in a > container that includes the NFS utils all those files actually show up > as "nfsnobody"-owned now, even though there's no relation to NFS at all > for them. And this is where the shift in behavior would get confusing. > How could a transition look like? I figure new installs should get > "nobody" defined to 65534. Old installs should keep the old > definitions in place instead. The NFS packages should be updated to > not create the "nfsnobody" user if there's already another user mapped > to 65534 (maybe it already does that?). Of course it's not pretty if > old and new systems use different definitions for this user, but I > think it's not too much of a real-life issue, as most code that refers > to this group already does so by UID instead of name, simply because > the name is not stable across distributions. Like I said, I'm thinking of "rsync", "tar", and "star". Also, people do some interesting scripting to detect things like failed NFS configurations. I'm not saying that's a blocker, but shifting it to overlap with the current "nfsnobody" is likely to break some people's tools in the field, especially if they run the latest Fedora alongside RHEL, CentOS, or previous Fedora releases. > Opinions? > > Lennart > > -- > Lennart Poettering, Red Hat > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On Tue, 19.07.16 11:17, James Hogarth (james.hoga...@gmail.com) wrote: > On 19 July 2016 at 10:59, Lennart Poetteringwrote: > > > On Mon, 18.07.16 17:45, Sam Varshavchik (mr...@courier-mta.com) wrote: > > > > > Lennart Poettering writes: > > > > > > >On Fedora, we currently have a "nobody" user that is defined to UID > > > >99. It's defined unconditionally like this. To my knowledge there's no > > > >actual use of this user at all in Fedora however. > > > > > > I see distccd running as the nobody user. > > > > > > I also see dnsmasq running as the nobody user. > > > > Urks, this looks broken. Don't our package guidelines prohibit this? > > > > > > > I don't see anything in the overall guidelines[1], the users_and_groups > guidelines[2] or the systemd_unit guidelines[3] > > A quick search of FPC tickets doesn't show any discussion there either. > > [1] https://fedoraproject.org/wiki/Packaging:Guidelines > [2] https://fedoraproject.org/wiki/Packaging:UsersAndGroups > [3] https://fedoraproject.org/wiki/Packaging:Systemd Hmm, OK. I filed an FPC ticket about this now: https://fedorahosted.org/fpc/ticket/642 Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On 19 July 2016 at 10:59, Lennart Poetteringwrote: > On Mon, 18.07.16 17:45, Sam Varshavchik (mr...@courier-mta.com) wrote: > > > Lennart Poettering writes: > > > > >On Fedora, we currently have a "nobody" user that is defined to UID > > >99. It's defined unconditionally like this. To my knowledge there's no > > >actual use of this user at all in Fedora however. > > > > I see distccd running as the nobody user. > > > > I also see dnsmasq running as the nobody user. > > Urks, this looks broken. Don't our package guidelines prohibit this? > > > I don't see anything in the overall guidelines[1], the users_and_groups guidelines[2] or the systemd_unit guidelines[3] A quick search of FPC tickets doesn't show any discussion there either. [1] https://fedoraproject.org/wiki/Packaging:Guidelines [2] https://fedoraproject.org/wiki/Packaging:UsersAndGroups [3] https://fedoraproject.org/wiki/Packaging:Systemd -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On Mon, 18.07.16 17:45, Sam Varshavchik (mr...@courier-mta.com) wrote: > Lennart Poettering writes: > > >On Fedora, we currently have a "nobody" user that is defined to UID > >99. It's defined unconditionally like this. To my knowledge there's no > >actual use of this user at all in Fedora however. > > I see distccd running as the nobody user. > > I also see dnsmasq running as the nobody user. Urks, this looks broken. Don't our package guidelines prohibit this? Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On Mon, 18.07.16 17:00, Ondřej Vašík (ova...@redhat.com) wrote: > > So what do you propose instead? Just stick our heads in the sand, > > ignore the issue, accept that in containers all files in /proc now > > sometimes show up as owned by the literal "65534" user and sometimes > > as owned by "nfsnobody", depending on whether the NFS utils package is > > in the mix or not, even though userns has really *nothing* to do with > > NFS? > > No, that's not my proposal as you can read in my "we should find some > way how to solve it." ;) > > I even proposed other way - changing overflowid/overflowgid > through /proc/sys/fs/overflowgid and /proc/sys/fs/overflowuid - that > should work - although changing documented defaults is usually not the > best way - so I don't think this is the right way to solve this > either. I'd be be very careful with that, as this would mean files with the old UIDs would suddenly change ownership, and code might lose access. I am pretty sure that of the two bad solutions of changing the name of the user or changing the UID of it, the latter is much worse than the former... > > Another option could be to simply define both name mappings in > > /etc/passwd. i.e. list both the nfsnobody → 65534 mapping in it as > > well as nobody → 65534. This is only semi-supported though, and might > > just shift brokeness around... (a slightly different alternative could > > be to implement the "nobody" mapping in an explicit NSS module that is > > ordered after "files", and drop it from /etc/passwd. That way whatever > > is defined in /etc/passwd would take precedence, but if "nobody" is > > explicitly requested it would also be mapped, but would not show up in > > the user listing of "getent passwd". In effect, /etc/passwd and > > "getent passwd" would only show unique UID mappings that way, even > > though "nobody" stays always resolvable). > > Mapping of both names to same ID through file precedence is not going to > solve this issue when nfs-utils package is installed. nfsnobody will own > some of the /proc files, confusing users. I like the NSS module a bit > more than "nobody->65534 , nfsnobody->get out" - especially if this will > be part of the systems where user namespaces are likely - to the > containers. Can be solution for most of the usecases (except the > container with nfs-utils installed). The NSS option would work for me too. In fact, I am tempted to just ship an NSS module along with systemd that maps UIDs 0 and 65534 like this, if they aren't listed properly in /etc/passwd. Having that would be pretty neat as container-like environments could drop their passwd database entirely and still get useful resolution of the two most relevant UIDs in this context. > In my opinion, simple solution is bad solution here. Maybe another > solution can be to define safe namespaces for system users - something > like _$name on OS X - however this is more complex than simple rename. IIRC Debian adopted a similar scheme. Newly allocated system users need to begin with an underscore. I am pretty sure Fedora should adopt a similar scheme, at least for user/group names allocated from now on... But that's a different discussion... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On Mon, Jul 18, 2016 at 2:45 PM, Sam Varshavchikwrote: > Lennart Poettering writes: > >> On Fedora, we currently have a "nobody" user that is defined to UID >> 99. It's defined unconditionally like this. To my knowledge there's no >> actual use of this user at all in Fedora however. > > > I see distccd running as the nobody user. > > I also see dnsmasq running as the nobody user. This practice needs to end. For example, unless the offending code uses a PID namespace, you can ptrace another 'nobody' process, steal an fd pointing out of the chroot, and break out. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
Lennart Poettering writes: On Fedora, we currently have a "nobody" user that is defined to UID 99. It's defined unconditionally like this. To my knowledge there's no actual use of this user at all in Fedora however. I see distccd running as the nobody user. I also see dnsmasq running as the nobody user. It is a very popular pastime to take a listening daemon and chroot-jail it as the nobody user. I'm sure there's a bunch of other stuff in Fedora that does this. These are just the ones running on my box. It's unlikely that changing the nobody uid and gid will have any regressions. However, it's not true that nothing uses nobody. nobody is quite popular. pgpiJw1M61HRX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On Mon, Jul 18, 2016 at 05:00:40PM +0200, Ondřej Vašík wrote: > Lennart Poettering píše v Po 18. 07. 2016 v 16:28 +0200: > > On Mon, 18.07.16 15:59, Ondřej Vašík (ova...@redhat.com) wrote: > > > > > Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200: > > > > Heya! > > > > > > > > I'd like to start a discussion regarding the "nobody" user on Fedora, > > > > and propose that we change its definition sooner or later. I am not > > > > proposing a feature according to the feature process for this yet, but > > > > my hope is that these discussions will lead to one eventually. > > > > > > Thanks for starting the discussion on Fedora devel - as there already > > > was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended > > > up closed NOTABUG - as the nfs-utils maintainer is concerned about such > > > change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and > > > most of commenters (moved across several components) recommended "not a > > > bug" resolution. > > > > > > I agree with containers and user namespaces, overflow uid named > > > "nfsnobody" confuses users. But is there really some good and > > > non-disruptive solution? e.g. Overflow id can be changed to different > > > than (uint_16_t) -2, but it is the right way? > > > > Nah, why change it, that certainly would break more things than just > > renaming the user name of it. > > It is just other way of solving this issue. Nobody tried this, nobody > can say whether this will break more things than changing nobody to > different nobody ;). We can speculate what kind of breakage is possible when we do either change: If the numerical id of a user changes, files on disk there were created under the old id will now be owned by a different user. If we provide a compat name for the old numerical id, those files will show under that user, and if we don't, it will show as the numerical value. This is a cosmetic thing; what is more important is that if any files on disk will become inaccessible. This means that we do not want to change the numerical id for which any files exist. And I think nfsnobody (or rather the overflow uid) falls into this category; e.g. it is likely to inadvertently create such files by copying something as root in a container. OTOH, changing the name of a user has a different set of pitfalls: anything referring to the old name will stop working. So simply changing the name is not really an option. > Lennart Poettering píše v Po 18. 07. 2016 v 16:28 +0200: > > Another option could be to simply define both name mappings in > > /etc/passwd. i.e. list both the nfsnobody → 65534 mapping in it as > > well as nobody → 65534. This is only semi-supported though, and might > > just shift brokeness around... IMHO this is the best option. Tools that read /etc/passwd stop at the first matching entry, so 65534 will be resolved to nobody, and nfsnobody will be resolved to 65534 as before. AFAIK, people have used this trick to map multiple users to 0 for a long time, so it should mostly work. I just did that change locally, and names are resolved properly, pwck reports no errors. A potential pitfall could be other tools which munge /etc/passwd or /etc/group getting confused. Enabling this in rawhide should expose any if they exist. > > a slightly different alternative could > > be to implement the "nobody" mapping in an explicit NSS module that is > > ordered after "files" The hard part will be inserting the module in the right place. This is a similar problem as the (unsolved) issues with "hosts:" line. It is hard to detect local modifications to nsswitch.conf, and impossible to do any automatic change if any are detected. My proposal: add oldnobody:x:99:99:Old unmapped user:/:/sbin/nologin nobody:x:65534:65534:Unmapped user:/:/sbin/nologin nfsnobody:x:65534:65534:Unmapped User:/:/sbin/nologin in /etc/passwd, and matching lines in /etc/group. Let's do this statically in setup.rpm, and remove the manipulation of nfsnobody from nfs-utils.rpm. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
Lennart Poettering píše v Po 18. 07. 2016 v 16:28 +0200: > On Mon, 18.07.16 15:59, Ondřej Vašík (ova...@redhat.com) wrote: > > > Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200: > > > Heya! > > > > > > I'd like to start a discussion regarding the "nobody" user on Fedora, > > > and propose that we change its definition sooner or later. I am not > > > proposing a feature according to the feature process for this yet, but > > > my hope is that these discussions will lead to one eventually. > > > > Thanks for starting the discussion on Fedora devel - as there already > > was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended > > up closed NOTABUG - as the nfs-utils maintainer is concerned about such > > change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and > > most of commenters (moved across several components) recommended "not a > > bug" resolution. > > > > I agree with containers and user namespaces, overflow uid named > > "nfsnobody" confuses users. But is there really some good and > > non-disruptive solution? e.g. Overflow id can be changed to different > > than (uint_16_t) -2, but it is the right way? > > Nah, why change it, that certainly would break more things than just > renaming the user name of it. It is just other way of solving this issue. Nobody tried this, nobody can say whether this will break more things than changing nobody to different nobody ;). > > > Another option would be to define an entirely new user name for 65534, > > > for example "void" or so. But quite frankly, that sounds like a > > > pointless bikeshedding excercise, and creates even more confusion, > > > balkanization and political hassles if you'd try to convince other > > > distros to adopt the same scheme too. > > > > > > Hence, let's go for "nobody == 65534" on Fedora too! And let's unify > > > the various dsitributions a tiny bit more, on this specific aspect. > > > > And potentially break some scripts that rely either on "nfsnobody" or on > > id. This is something where we don't have control over it. > > Well, we have a process in Fedora for implementing features: come up > with a reasonable strategy for a transition, implement it in Rawhide, > and rollback if it breaks too much stuff. > > > > How could a transition look like? I figure new installs should get > > > "nobody" defined to 65534. Old installs should keep the old > > > definitions in place instead. The NFS packages should be updated to > > > not create the "nfsnobody" user if there's already another user mapped > > > to 65534 (maybe it already does that?). Of course it's not pretty if > > > old and new systems use different definitions for this user, but I > > > think it's not too much of a real-life issue, as most code that refers > > > to this group already does so by UID instead of name, simply because > > > the name is not stable across distributions. > > > > > > Opinions? > > > > I agree having uid -2 named "nfsnobody" is just confusing with user > > namespaces and containers - and we should find some way how to solve it. > > I don't agree that changing 99 "nobody" to 65534 "nobody" in > > default /etc/passwd and not using "nfsnobody" in default new nfs-utils > > installations is the right way to solve the issue. It might be less > > confusing for some users and more in sync with Debian (and less with > > e.g. ArchLinux), but has the potential to break something and imho > > brings only very low benefit. > > So what do you propose instead? Just stick our heads in the sand, > ignore the issue, accept that in containers all files in /proc now > sometimes show up as owned by the literal "65534" user and sometimes > as owned by "nfsnobody", depending on whether the NFS utils package is > in the mix or not, even though userns has really *nothing* to do with > NFS? No, that's not my proposal as you can read in my "we should find some way how to solve it." ;) I even proposed other way - changing overflowid/overflowgid through /proc/sys/fs/overflowgid and /proc/sys/fs/overflowuid - that should work - although changing documented defaults is usually not the best way - so I don't think this is the right way to solve this either. > I mean, we can certainly stop developing Fedora, because of fear that > fixing things might break apps we never heard of that rely on a very > specific bug or misdesign in some very specific software. But I am not > convinced that fear-driven development is really the best strategy to > win the future... > > Another option could be to simply define both name mappings in > /etc/passwd. i.e. list both the nfsnobody → 65534 mapping in it as > well as nobody → 65534. This is only semi-supported though, and might > just shift brokeness around... (a slightly different alternative could > be to implement the "nobody" mapping in an explicit NSS module that is > ordered after "files", and drop it from /etc/passwd. That way whatever > is defined in /etc/passwd would take precedence,
Re: RFC: Fixing the "nobody" user?
On Mon, 18.07.16 15:59, Ondřej Vašík (ova...@redhat.com) wrote: > Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200: > > Heya! > > > > I'd like to start a discussion regarding the "nobody" user on Fedora, > > and propose that we change its definition sooner or later. I am not > > proposing a feature according to the feature process for this yet, but > > my hope is that these discussions will lead to one eventually. > > Thanks for starting the discussion on Fedora devel - as there already > was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended > up closed NOTABUG - as the nfs-utils maintainer is concerned about such > change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and > most of commenters (moved across several components) recommended "not a > bug" resolution. > > I agree with containers and user namespaces, overflow uid named > "nfsnobody" confuses users. But is there really some good and > non-disruptive solution? e.g. Overflow id can be changed to different > than (uint_16_t) -2, but it is the right way? Nah, why change it, that certainly would break more things than just renaming the user name of it. > > Another option would be to define an entirely new user name for 65534, > > for example "void" or so. But quite frankly, that sounds like a > > pointless bikeshedding excercise, and creates even more confusion, > > balkanization and political hassles if you'd try to convince other > > distros to adopt the same scheme too. > > > > Hence, let's go for "nobody == 65534" on Fedora too! And let's unify > > the various dsitributions a tiny bit more, on this specific aspect. > > And potentially break some scripts that rely either on "nfsnobody" or on > id. This is something where we don't have control over it. Well, we have a process in Fedora for implementing features: come up with a reasonable strategy for a transition, implement it in Rawhide, and rollback if it breaks too much stuff. > > How could a transition look like? I figure new installs should get > > "nobody" defined to 65534. Old installs should keep the old > > definitions in place instead. The NFS packages should be updated to > > not create the "nfsnobody" user if there's already another user mapped > > to 65534 (maybe it already does that?). Of course it's not pretty if > > old and new systems use different definitions for this user, but I > > think it's not too much of a real-life issue, as most code that refers > > to this group already does so by UID instead of name, simply because > > the name is not stable across distributions. > > > > Opinions? > > I agree having uid -2 named "nfsnobody" is just confusing with user > namespaces and containers - and we should find some way how to solve it. > I don't agree that changing 99 "nobody" to 65534 "nobody" in > default /etc/passwd and not using "nfsnobody" in default new nfs-utils > installations is the right way to solve the issue. It might be less > confusing for some users and more in sync with Debian (and less with > e.g. ArchLinux), but has the potential to break something and imho > brings only very low benefit. So what do you propose instead? Just stick our heads in the sand, ignore the issue, accept that in containers all files in /proc now sometimes show up as owned by the literal "65534" user and sometimes as owned by "nfsnobody", depending on whether the NFS utils package is in the mix or not, even though userns has really *nothing* to do with NFS? I mean, we can certainly stop developing Fedora, because of fear that fixing things might break apps we never heard of that rely on a very specific bug or misdesign in some very specific software. But I am not convinced that fear-driven development is really the best strategy to win the future... Another option could be to simply define both name mappings in /etc/passwd. i.e. list both the nfsnobody → 65534 mapping in it as well as nobody → 65534. This is only semi-supported though, and might just shift brokeness around... (a slightly different alternative could be to implement the "nobody" mapping in an explicit NSS module that is ordered after "files", and drop it from /etc/passwd. That way whatever is defined in /etc/passwd would take precedence, but if "nobody" is explicitly requested it would also be mapped, but would not show up in the user listing of "getent passwd". In effect, /etc/passwd and "getent passwd" would only show unique UID mappings that way, even though "nobody" stays always resolvable). Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
On 18 July 2016 at 08:39, Lennart Poetteringwrote: > Heya! > > I'd like to start a discussion regarding the "nobody" user on Fedora, > and propose that we change its definition sooner or later. I am not > proposing a feature according to the feature process for this yet, but > my hope is that these discussions will lead to one eventually. > I am not against this proposal. It has been tried at least once before in the past but those failed due to a lot of programs secretly relying on the seperate uids and not a lot of people being able to fix it. I am not 100% certain that it was mostly 99 due to issues with various network authentication systems from long ago. (ypbind/ldap/etc) where the MAX-2 UID was not assigned to nobody but some other system account. I think this is why SUSE went with the range of uids because MAX-1 -> MAX-16 was used in various OS's for a large amount of system accounts. That is from a time when the world was rules by UNIX and Linux was a little thing. These days it is a different matter and we can try and be more flexible. I would say that UID 99 is going to need to be set to oldnobody or some such thing because of the upgraders versus fresh installers and it will need to be kept that way for the eventual EL branch. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: RFC: Fixing the "nobody" user?
Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200: > Heya! > > I'd like to start a discussion regarding the "nobody" user on Fedora, > and propose that we change its definition sooner or later. I am not > proposing a feature according to the feature process for this yet, but > my hope is that these discussions will lead to one eventually. Thanks for starting the discussion on Fedora devel - as there already was https://bugzilla.redhat.com/show_bug.cgi?id=1350526 - where it ended up closed NOTABUG - as the nfs-utils maintainer is concerned about such change ( https://bugzilla.redhat.com/show_bug.cgi?id=1350526#c3 ) - and most of commenters (moved across several components) recommended "not a bug" resolution. I agree with containers and user namespaces, overflow uid named "nfsnobody" confuses users. But is there really some good and non-disruptive solution? e.g. Overflow id can be changed to different than (uint_16_t) -2, but it is the right way? > Most distributions (in particular Debian/Ubuntu-based ones) map the > user "nobody" to UID 65534. I think we should change Fedora to do the > same. Background: > > On Linux two UIDs are special: that's UID 0 for root, which is the > privileged user we all know. And then there's UID 65534 > (i.e. (uint16_t) -2), which is less well known. The Linux kernel calls > it the "overflow" UID. It has four purposes: > > 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs >only supports 16bit UIDs, but a 32bit UID is passed to it. > > 2. it's used by the kernel's user namespacing as a the internal UID >that external UIDs are mapped to that don't have any local mapping. > > 3. It's used by NFS for all user IDs that cannot be mapped locally if >UID mapping is enabled. > > 4. One upon a time some system daemons chose to run as the "nobody" >user, instead of a proper system user of their own. But this is >universally frowned upon, and isn't done on any current systems >afaics. In fact, to my knowledge Fedora even prohibits this >explicitly in its policy (?). > > The uses 1-3 are relevant today, use 4 is clearly obsolete > afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something > that cannot be mapped properly is mapped to". > > On Fedora, we currently have a "nobody" user that is defined to UID > 99. It's defined unconditionally like this. To my knowledge there's no > actual use of this user at all in Fedora however. The UID 65514 > carries no name by default on Fedora, but as soon as you install the > NFS utils it gets mapped to the "nfsnobody" user name, misleadingly > indicating that it would be used only by NFS even though it's a much > more general concept. I figure the NFS guys adopted the name > "nfsnobody" for this, simply because "nobody" was already taken by UID > 99 on Fedora, unlike on other distributions. It is really a historical reason. I don't think there was common agreement at the time when 99 for nobody was selected (at least several different approaches were in place these days). > In the context of user namespacing the UID 65534 appears a lot more > often as owner of various files. For example, if you turn on user > namespacing in typical container managers you'll notice that a ton of > files in /proc will then be owned by this user. Very confusingly, in a > container that includes the NFS utils all those files actually show up > as "nfsnobody"-owned now, even though there's no relation to NFS at all > for them. > > I'd like to propose that we clean this up, and just make Fedora work > like all other distributions. After all the reason of having this > special UID in the first place is to sidestep mapping problems between > different UID "realms". Hence I think it would be wise to at least > make the name of this very special UID somewhat more stable and > well-defined between distributions. > > I think this is of particular relevance as Debian/Ubuntu-based > container images tend to be substantially more popular than > Fedora-based ones, and hence I think we should try to unify at least > the names and semantics of the two special UIDs all distros have, to > minimize mapping problems and making user interaction in containers a > bit more friendly. > > You might ask of course, why Fedora should change to adopt > Debian's/Ubuntu's definition, instead of conversely making them adopt > Fedora's definition? Well, that's simple: Debian's definition makes a > lot more sense than Fedora's. And nothing we ship actually makes use > of FEdora's definition afaics, and we currently carry a workaround > called "nfsnobody" in some cases to avoid having to fix this properly. It is not just Fedora, ArchLinux uses 99 nobody as well - as far as I know. And probably some other systems as well. Debian, Ubuntu and OpenSUSE use 65534 (although OpenSUSE seems to use 65534:65533 to add even more confusion) Citing Wiki: "Nobody: Historically, the user “nobody” was assigned UID -2 by several operating
Re: RFC: Fixing the "nobody" user?
On Mon, Jul 18, 2016 at 8:39 AM, Lennart Poetteringwrote: > Heya! > > I'd like to start a discussion regarding the "nobody" user on Fedora, > and propose that we change its definition sooner or later. I am not > proposing a feature according to the feature process for this yet, but > my hope is that these discussions will lead to one eventually. > > Most distributions (in particular Debian/Ubuntu-based ones) map the > user "nobody" to UID 65534. I think we should change Fedora to do the > same. Background: > > On Linux two UIDs are special: that's UID 0 for root, which is the > privileged user we all know. And then there's UID 65534 > (i.e. (uint16_t) -2), which is less well known. The Linux kernel calls > it the "overflow" UID. It has four purposes: > > 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs >only supports 16bit UIDs, but a 32bit UID is passed to it. > > 2. it's used by the kernel's user namespacing as a the internal UID >that external UIDs are mapped to that don't have any local mapping. > > 3. It's used by NFS for all user IDs that cannot be mapped locally if >UID mapping is enabled. > > 4. One upon a time some system daemons chose to run as the "nobody" >user, instead of a proper system user of their own. But this is >universally frowned upon, and isn't done on any current systems >afaics. In fact, to my knowledge Fedora even prohibits this >explicitly in its policy (?). > > The uses 1-3 are relevant today, use 4 is clearly obsolete > afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something > that cannot be mapped properly is mapped to". > > On Fedora, we currently have a "nobody" user that is defined to UID > 99. It's defined unconditionally like this. To my knowledge there's no > actual use of this user at all in Fedora however. The UID 65514 > carries no name by default on Fedora, but as soon as you install the > NFS utils it gets mapped to the "nfsnobody" user name, misleadingly > indicating that it would be used only by NFS even though it's a much > more general concept. I figure the NFS guys adopted the name > "nfsnobody" for this, simply because "nobody" was already taken by UID > 99 on Fedora, unlike on other distributions. > > In the context of user namespacing the UID 65534 appears a lot more > often as owner of various files. For example, if you turn on user > namespacing in typical container managers you'll notice that a ton of > files in /proc will then be owned by this user. Very confusingly, in a > container that includes the NFS utils all those files actually show up > as "nfsnobody"-owned now, even though there's no relation to NFS at all > for them. > > I'd like to propose that we clean this up, and just make Fedora work > like all other distributions. After all the reason of having this > special UID in the first place is to sidestep mapping problems between > different UID "realms". Hence I think it would be wise to at least > make the name of this very special UID somewhat more stable and > well-defined between distributions. > > I think this is of particular relevance as Debian/Ubuntu-based > container images tend to be substantially more popular than > Fedora-based ones, and hence I think we should try to unify at least > the names and semantics of the two special UIDs all distros have, to > minimize mapping problems and making user interaction in containers a > bit more friendly. > > You might ask of course, why Fedora should change to adopt > Debian's/Ubuntu's definition, instead of conversely making them adopt > Fedora's definition? Well, that's simple: Debian's definition makes a > lot more sense than Fedora's. And nothing we ship actually makes use > of FEdora's definition afaics, and we currently carry a workaround > called "nfsnobody" in some cases to avoid having to fix this properly. > > Another option would be to define an entirely new user name for 65534, > for example "void" or so. But quite frankly, that sounds like a > pointless bikeshedding excercise, and creates even more confusion, > balkanization and political hassles if you'd try to convince other > distros to adopt the same scheme too. > > Hence, let's go for "nobody == 65534" on Fedora too! And let's unify > the various dsitributions a tiny bit more, on this specific aspect. > > How could a transition look like? I figure new installs should get > "nobody" defined to 65534. Old installs should keep the old > definitions in place instead. The NFS packages should be updated to > not create the "nfsnobody" user if there's already another user mapped > to 65534 (maybe it already does that?). Of course it's not pretty if > old and new systems use different definitions for this user, but I > think it's not too much of a real-life issue, as most code that refers > to this group already does so by UID instead of name, simply because > the name is not stable across distributions. > > Opinions? > Not an opinion but some
RFC: Fixing the "nobody" user?
Heya! I'd like to start a discussion regarding the "nobody" user on Fedora, and propose that we change its definition sooner or later. I am not proposing a feature according to the feature process for this yet, but my hope is that these discussions will lead to one eventually. Most distributions (in particular Debian/Ubuntu-based ones) map the user "nobody" to UID 65534. I think we should change Fedora to do the same. Background: On Linux two UIDs are special: that's UID 0 for root, which is the privileged user we all know. And then there's UID 65534 (i.e. (uint16_t) -2), which is less well known. The Linux kernel calls it the "overflow" UID. It has four purposes: 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs only supports 16bit UIDs, but a 32bit UID is passed to it. 2. it's used by the kernel's user namespacing as a the internal UID that external UIDs are mapped to that don't have any local mapping. 3. It's used by NFS for all user IDs that cannot be mapped locally if UID mapping is enabled. 4. One upon a time some system daemons chose to run as the "nobody" user, instead of a proper system user of their own. But this is universally frowned upon, and isn't done on any current systems afaics. In fact, to my knowledge Fedora even prohibits this explicitly in its policy (?). The uses 1-3 are relevant today, use 4 is clearly obsolete afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something that cannot be mapped properly is mapped to". On Fedora, we currently have a "nobody" user that is defined to UID 99. It's defined unconditionally like this. To my knowledge there's no actual use of this user at all in Fedora however. The UID 65514 carries no name by default on Fedora, but as soon as you install the NFS utils it gets mapped to the "nfsnobody" user name, misleadingly indicating that it would be used only by NFS even though it's a much more general concept. I figure the NFS guys adopted the name "nfsnobody" for this, simply because "nobody" was already taken by UID 99 on Fedora, unlike on other distributions. In the context of user namespacing the UID 65534 appears a lot more often as owner of various files. For example, if you turn on user namespacing in typical container managers you'll notice that a ton of files in /proc will then be owned by this user. Very confusingly, in a container that includes the NFS utils all those files actually show up as "nfsnobody"-owned now, even though there's no relation to NFS at all for them. I'd like to propose that we clean this up, and just make Fedora work like all other distributions. After all the reason of having this special UID in the first place is to sidestep mapping problems between different UID "realms". Hence I think it would be wise to at least make the name of this very special UID somewhat more stable and well-defined between distributions. I think this is of particular relevance as Debian/Ubuntu-based container images tend to be substantially more popular than Fedora-based ones, and hence I think we should try to unify at least the names and semantics of the two special UIDs all distros have, to minimize mapping problems and making user interaction in containers a bit more friendly. You might ask of course, why Fedora should change to adopt Debian's/Ubuntu's definition, instead of conversely making them adopt Fedora's definition? Well, that's simple: Debian's definition makes a lot more sense than Fedora's. And nothing we ship actually makes use of FEdora's definition afaics, and we currently carry a workaround called "nfsnobody" in some cases to avoid having to fix this properly. Another option would be to define an entirely new user name for 65534, for example "void" or so. But quite frankly, that sounds like a pointless bikeshedding excercise, and creates even more confusion, balkanization and political hassles if you'd try to convince other distros to adopt the same scheme too. Hence, let's go for "nobody == 65534" on Fedora too! And let's unify the various dsitributions a tiny bit more, on this specific aspect. How could a transition look like? I figure new installs should get "nobody" defined to 65534. Old installs should keep the old definitions in place instead. The NFS packages should be updated to not create the "nfsnobody" user if there's already another user mapped to 65534 (maybe it already does that?). Of course it's not pretty if old and new systems use different definitions for this user, but I think it's not too much of a real-life issue, as most code that refers to this group already does so by UID instead of name, simply because the name is not stable across distributions. Opinions? Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org