On Fri, Jan 12, 2018 at 11:19 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > On 01/12/2018 10:57 AM, Daniel Walsh wrote: >> On 01/12/2018 10:41 AM, Steve Dickson wrote: >>> >>> 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. >> Having this in the kernel and actually anyone using it are two different things. We are just beginning to finally use this now. > Ah... this explains the exposure of nfsnobody... > > So if its just beginning to be used... we can change the defaults... right? :-) > >>> >>>>>> 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. >> Well in UserNamespace it happens all the time. Basically any Inode that is owned by a uid that is not mapped in the usernamespace will be reported as this UID. > Ok... understood. > >>>> 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. >> It is not rare. >>> 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'? >> You would force everyone everwhere to make this change. > If I'm understanding your question... Yes this would be a fedora-only > thing... but so what? We have a lot of Fedora only things. > > Side Note: I have a ping out to a SUSE guy to see how they handle this > but the guy lives on the other side of the earth so I probably > will not get a response until tomorrow. I can tell you what that is, as I run (open)SUSE systems. SUSE systems set the following in their /etc/passwd: nobody:x:65534:65533:nobody:/var/lib/nobody:/bin/bash This is what they set for /etc/group: nobody:x:65533: nogroup:x:65534:nobody This only varies slightly from what Mageia and Debian/Ubuntu do in that nobody is both a member of nogroup but has its own nobody group. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
