Hi Eric,
I'm still hoping for a revised patch from you in the light
of Andy's comments and question.
Thanks,
Michael
On 09/30/2014 04:16 AM, Andy Lutomirski wrote:
> On Mon, Sep 29, 2014 at 7:15 PM, Eric W. Biederman
> <[email protected]> wrote:
>> Andy Lutomirski <[email protected]> writes:
>>
>>> On Mon, Sep 29, 2014 at 6:04 PM, Eric W. Biederman
>>> <[email protected]> wrote:
>>>>
>>>> I recently realized that I had been reasoning improperly about what
>>>> umount(MNT_DETACH) did based on an insufficient description in
>>>> the umount.2 man page, that matched my intuition but not the
>>>> implementation.
>>>>
>>>> When there are no submounts MNT_DETACH is essentially harmless to
>>>> applications. Where there are submounts MNT_DETACH changes what
>>>> is visible to applications using the detach directories.
>>>>
>>>> Signed-off-by: Eric W. Biederman <[email protected]>
>>>> ---
>>>> man2/umount.2 | 7 ++++---
>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/man2/umount.2 b/man2/umount.2
>>>> index 5ff88152c738..aea39d8306fe 100644
>>>> --- a/man2/umount.2
>>>> +++ b/man2/umount.2
>>>> @@ -66,9 +66,10 @@ This can cause data loss.
>>>> (Only for NFS mounts.)
>>>> .TP
>>>> .BR MNT_DETACH " (since Linux 2.4.11)"
>>>> -Perform a lazy unmount: make the mount point unavailable for
>>>> -new accesses, and actually perform the unmount when the mount point
>>>> -ceases to be busy.
>>>> +Perform a lazy unmount: make the mount point unavailable for new
>>>> +accesses, immediately disconnect the filesystem and all filesystems
>>>> +mounted below it from each other and from the mount table, and
>>>> +actually perform the unmount when the mount point ceases to be busy.
>>>
>>> Want to add something like:
>>>
>>> MNT_DETACH on a shared mount will propagate unmount events to its peer
>>> group. That means that recursively bind mounting a shared mount and
>>> then unmounting that recursive bind mount will unmount all submounts
>>> of the original mount. This behavior can be avoided by remounting a
>>> directory with MS_REC | MS_PRIVATE before unmounting it.
>>
>> Make that any unmount on a shared mount that will propogate unmount
>> events to it's peer group.
>
> I don't understand your proposed edit. Can you type it out explicitly?
>
> --Andy
>
>>
>> Eric
>>
>
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
"Michael Kerrisk (man-pages)" <[email protected]> writes:
> Hi Eric,
>
> I'm still hoping for a revised patch from you in the light
> of Andy's comments and question.
Andy's concerns are orthogonal to my original patch, and
actually have nothing to do with MNT_DETACH.
Which was my point but here I will send a second patch on top of my
first patch to document the effect of shared mounts in umount.2
Eric
Signed-off-by: Eric W. Biederman <[email protected]>
---
man2/umount.2 | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/man2/umount.2 b/man2/umount.2
index aea39d8306fe..a0120b2fc811 100644
--- a/man2/umount.2
+++ b/man2/umount.2
@@ -97,6 +97,24 @@ Don't dereference
if it is a symbolic link.
This flag allows security problems to be avoided in set-user-ID-\fIroot\fP
programs that allow unprivileged users to unmount filesystems.
+
+.P
+Shared mount points cause any mount activity on that mount point
+including umounts to be forwarded to every shared mount point in it's
+peer group and every slave mount of that peer group. This means that
+umount of any peer in a set of shared mounts will cause all of it's
+peers to be unmounted and all of their slaves to be unmounted as well.
+
+This propogagtion of unmount activity can be particularly surprising
+on systems where every mount point is shared by default. On such
+systems recursively bind mounting the root directory of the filesystem
+onto a subdirectory and then later unmounting that subdirectory with
+.BR MNT_DETACH
+will cause every mount in the mount namespace to be lazily unmounted.
+
+To ensure umount does not propagate the mount point may be
+remounted with MS_REC | MS_PRIVATE prior to umount being called.
+
.SH RETURN VALUE
On success, zero is returned.
On error, \-1 is returned, and
--
1.9.1
On 10/28/2014 06:33 PM, Eric W. Biederman wrote:
>
> Signed-off-by: Eric W. Biederman <[email protected]>
Thanks, Eric. Again, sorry for the delay. I've applied this
patch.
Cheers,
Michael
> ---
> man2/umount.2 | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/man2/umount.2 b/man2/umount.2
> index aea39d8306fe..a0120b2fc811 100644
> --- a/man2/umount.2
> +++ b/man2/umount.2
> @@ -97,6 +97,24 @@ Don't dereference
> if it is a symbolic link.
> This flag allows security problems to be avoided in set-user-ID-\fIroot\fP
> programs that allow unprivileged users to unmount filesystems.
> +
> +.P
> +Shared mount points cause any mount activity on that mount point
> +including umounts to be forwarded to every shared mount point in it's
> +peer group and every slave mount of that peer group. This means that
> +umount of any peer in a set of shared mounts will cause all of it's
> +peers to be unmounted and all of their slaves to be unmounted as well.
> +
> +This propogagtion of unmount activity can be particularly surprising
> +on systems where every mount point is shared by default. On such
> +systems recursively bind mounting the root directory of the filesystem
> +onto a subdirectory and then later unmounting that subdirectory with
> +.BR MNT_DETACH
> +will cause every mount in the mount namespace to be lazily unmounted.
> +
> +To ensure umount does not propagate the mount point may be
> +remounted with MS_REC | MS_PRIVATE prior to umount being called.
> +
> .SH RETURN VALUE
> On success, zero is returned.
> On error, \-1 is returned, and
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/