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 (ovasik@xxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
