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, 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).
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.
Regards,
Ondrej
>
> Lennart
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
