[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5411B454.4010907@gmail.com>
Date: Thu, 11 Sep 2014 07:40:20 -0700
From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: mtk.manpages@...il.com, lkml <linux-kernel@...r.kernel.org>,
"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>,
containers@...ts.linux-foundation.org,
Andy Lutomirski <luto@...capital.net>,
richard.weinberger@...il.com, "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: For review: user_namespace(7) man page
On 09/09/2014 08:49 AM, Eric W. Biederman wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:
>
>> Hi Eric,
>>
>> On 08/30/2014 02:53 PM, Eric W. Biederman wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:
>>>
>>>> Hello Eric et al.,
>>>>
>>>> For various reasons, my work on the namespaces man pages
>>>> fell off the table a while back. Nevertheless, the pages have
>>>> been close to completion for a while now, and I recently restarted,
>>>> in an effort to finish them. As you also noted to me f2f, there have
>>>> been recently been some small namespace changes that you may affect
>>>> the content of the pages. Therefore, I'll take the opportunity to
>>>> send the namespace-related pages out for further (final?) review.
>>>>
>>>> So, here, I start with the user_namespaces(7) page, which is shown
>>>> in rendered form below, with source attached to this mail. I'll
>>>> send various other pages in follow-on mails.
>>>>
>>>> Review comments/suggestions for improvements / bug fixes welcome.
>>>>
>>>> Cheers,
>>>>
>>>> Michael
>>>>
>>>> ==
>>>>
>>>> NAME
>>>> user_namespaces - overview of Linux user_namespaces
>>>>
>> [...]
>>
>>>> When a new IPC, mount, network, PID, or UTS namespace is created
>>>> via clone(2) or unshare(2), the kernel records the user namespace
>>>> of the creating process against the new namespace. (This associ‐
>>>> ation can't be changed.) When a process in the new namespace
>>>> subsequently performs privileged operations that operate on
>>>> global resources isolated by the namespace, the permission checks
>>>> are performed according to the process's capabilities in the user
>>>> namespace that the kernel associated with the new namespace.
>>>
>>> Restrictions on mount namespaces.
>>>
>>> - A mount namespace has a owner user namespace. A mount namespace whose
>>> owner user namespace is different than the owerner user namespace of
>>> it's parent mount namespace is considered a less privileged mount
>>> namespace.
>>>
>>> - When creating a less privileged mount namespace shared mounts are
>>> reduced to slave mounts. This ensures that mappings performed in less
>>> privileged mount namespaces will not propogate to more privielged
>>> mount namespaces.
>>>
>>> - Mounts that come as a single unit from more privileged mount are
>>> locked together and may not be separated in a less privielged mount
>>> namespace.
>>
>> Could you clarify what you mean by "Mounts that come as a single
>> unit"?
>
> unshare(CLONE_NEWNS) brings across all of the mounts from the original
> mount namespace as a single unit.
>
> recursive mounts that propogate between mount namespaces propogate as a
> single unit.
Thanks, I've added those details to the page.
> The importance of this is allow the global root to mount over things
> and not have to worry that someone from a user namespace root can
> peek underneath.
>
>>> - The mount flags readonly, nodev, nosuid, noexec, and the mount atime
>>> settings when propogated from a more privielged to a less privileged
>>> mount namespace become locked, and may not be changed in the less
>>> privielged mount namespace.
>>>
>>> - (As of 3.18-rc1 (in todays Al Viros vfs.git#for-next tree)) A file or
>>> directory that is a mountpoint in one namespace that is not a mount
>>> point in another namespace, may be renamed, unlinked, or rmdired in
>>> the mount namespace in which it is not a mount namespace if the
>>> ordinary permission checks pass.
>>>
>>> Previously attemping to rmdir, unlink or rename a file or directory
>>> that was a mount point in another mount namespace would result in
>>> -EBUSY. This behavior had technical problems of enforcement (nfs)
>>> and resulted in a nice denial of servial attack against more
>>> privileged users. (Aka preventing individual files from being updated
>>> by bind mounting on top of them).
>>
>> I have reworked the text above a little so that now we have the following.
>> Aside from question above, does it look okay?
>>
>> Restrictions on mount namespaces
>> Note the following points with respect to mount namespaces:
>>
>> * A mount namespace has na owner user namespace. A mount
> ^s/na/an/
>> namespace whose owner user namespace is different from the
>> owner user namespace of its parent mount namespace is con‐
>> sidered a less privileged mount namespace.
>>
>> * When creating a less privileged mount namespace, shared
>> mounts are reduced to slave mounts. This ensures that map‐
>> pings performed in less privileged mount namespaces will not
>> propagate to more privileged mount namespaces.
>>
>> * Mounts that come as a single unit from more privileged mount
> ^ namespaces
>> are locked together and may not be separated in a less priv‐
>> ileged mount namespace.
>>
>> * The mount(2) flags MS_RDONLY, MS_NOSUID, MS_NOEXEC, and the
>> "atime" flags (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) set‐
>> tings become locked when propagated from a more privileged
>> to a less privileged mount namespace, and may not be changed
>> in the less privileged mount namespace.
>>
>> * A file or directory that is a mount point in one namespace
>> that is not a mount point in another namespace, may be
>> renamed, unlinked, or removed (rmdir(2)) in the mount names‐
>> pace in which it is not a mount point (subject to the usual
>> permission checks).
>>
>> Previously, attempting to unlink, rename, or remove a file
>> or directory that was a mount point in another mount names‐
>> pace would result in the error EBUSY. That behavior had
>> technical problems of enforcement (e.g., for NFS) and per‐
>> mitted denial-of-service attacks against more privileged
>> users. (i.e., preventing individual files from being
>> updated by bind mounting on top of them).
>
> Subject to tiny typo corrections that looks fine.
Yup, I already found and fixed ;-).
Thanks, Eric.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists