On Mon, 18.07.16 17:00, Ondřej Vašík (ovasik(a)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