lkml.org 
[lkml]   [2014]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: For review: user_namespace(7) man page
Hi Eric,

On 08/30/2014 02:53 PM, Eric W. Biederman wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.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"?

> - 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
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
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).

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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2014-09-09 16:41    [W:0.203 / U:1.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site