For review: user_namespace(7) man page
Eric W. Biederman
ebiederm at xmission.com
Tue Sep 9 15:51:49 UTC 2014
"Michael Kerrisk (man-pages)" <mtk.manpages at gmail.com> writes:
> On 08/30/2014 02:53 PM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages at gmail.com> writes:
> [...]
>
>
>>> The initial user namespace has no parent namespace, but, for con‐
>>> sistency, the kernel provides dummy user and group ID mapping
>>> files for this namespace. Looking at the uid_map file (gid_map
>>> is the same) from a shell in the initial namespace shows:
>>>
>>> $ cat /proc/$$/uid_map
>>> 0 0 4294967295
>>>
>>> This mapping tells us that the range starting at user ID 0 in
>>> this namespace maps to a range starting at 0 in the (nonexistent)
>>> parent namespace, and the length of the range is the largest
>>> 32-bit unsigned integer.
>>
>> Which deliberately leaves 4294967295 32bit (-1) unmapped. (uid_t)-1 is
>> used in several interfaces (like setreuid) as a way to specify no uid
>> leaving it unmapped and unusuable guarantees that there will be no
>> confusion when using those kernel methods.
>
> So, I worked that piece into the text to give:
>
> This mapping tells us that the range starting at user ID 0 in
> this namespace maps to a range starting at 0 in the (nonexis‐
> tent) parent namespace, and the length of the range is the
> largest 32-bit unsigned integer. (This deliberately leaves
> 4294967295 (the 32-bit signed -1 value) unmapped. This is
> deliberate: (uid_t) -1 is used in several interfaces (e.g.,
> setreuid(2)) as a way to specify "no user ID". Leaving
> setreuid(2)) unmapped and unusuable guarantees that there will
^^^^ (uid_t) -1 (not setreuid(2)
> be no confusion when using these interfaces.
>
> Okay?
Other than the typo fix above this looks good.
Eric
More information about the Containers
mailing list