On 01/12/2018 09:47 AM, Lennart Poettering wrote: > On Fr, 12.01.18 09:28, Steve Dickson (SteveD@xxxxxxxxxx) wrote: > >>> User namespacing is a Linux kernel feature. It's most well known >>> consumers are probably Docker, and maybe flatpak/bubblewrap and LXC. >> Well know for how long? > > The commit adding user namespaces to the Linux kernel was in 2007. 11 > years ago, in kernel 2.6.23. Wow... we've been living this way a long time... Seemly without any problems? If that is the case then I really don't see a need for this change that could potentially cause such havoc. > >>> It's not systemd that came up with reusing 65534 for user >>> namespacing. It's kernel people: >>> >>> $ cat /proc/sys/kernel/overflowuid >>> 65534 >> How was that number chosen and why can't be changed? > > It's conceptually the same thing: it's where UIDs are mapped that > cannot be mapped properly otherwise. Right... I'm assuming this overflow almost never happens from looking at the code. > > In theory you can change it by echoing something into sysctl, but > that's mostly theoretic, and not what the various consumers of userns > do. Understood. > > And regardless, it's conceptually the same thing anyway, so it makes a > ton of sense to use the UID there for both NFS and userns > purposes. While I have my reservations about userns in general the > logic behind using that UID for this purpose is very clear to me and > makes sense as far as I can see. > So the problem trying to be solved is when the overflow uid/gid are used (which is rarely), the owner of the file become nfsnobody which does not make any sense because it is on a local filesystem. If this is the case, my I suggest that since the overflow uid/gid is basically an arbitrary value and easily changeable... Why not have some boot process echo '99' into /proc/sys/kernel/overflowuid which would match nicely to a uid/gid of a user named 'nobody'? steved. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
