On 01/12/2018 09:47 AM, Lennart Poettering wrote:
On Fr, 12.01.18 09:28, Steve Dickson (SteveD(a)RedHat.com) 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.