On Mon, 18.07.16 17:00, Ondřej Vašík (ovasik@xxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
