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