Re: F28 System Wide Change: Rename "nobody" user

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

steved.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux