[PATCH] umount.2: Correct the description of MNT_DETACH

[PATCH] umount.2: Correct the description of MNT_DETACH

[Eric W. Biederman]

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 <ebiederm@xmission.com>
---
 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.
 .TP
 .BR MNT_EXPIRE " (since Linux 2.6.8)"
 Mark the mount point as expired.
-- 
1.9.1

Re: [PATCH] umount.2: Correct the description of MNT_DETACH

[Andy Lutomirski]

On Mon, Sep 29, 2014 at 6:04 PM, Eric W. Biederman
<ebiederm@xmission.com> 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 <ebiederm@xmission.com>
> ---
>  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.

--Andy

>  .TP
>  .BR MNT_EXPIRE " (since Linux 2.6.8)"
>  Mark the mount point as expired.
> --
> 1.9.1
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] umount.2: Correct the description of MNT_DETACH

[Eric W. Biederman]

Andy Lutomirski <luto@amacapital.net> writes:

> On Mon, Sep 29, 2014 at 6:04 PM, Eric W. Biederman
> <ebiederm@xmission.com> 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 <ebiederm@xmission.com>
>> ---
>>  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.

Eric

Re: [PATCH] umount.2: Correct the description of MNT_DETACH

[Andy Lutomirski]

On Mon, Sep 29, 2014 at 7:15 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
>
>> On Mon, Sep 29, 2014 at 6:04 PM, Eric W. Biederman
>> <ebiederm@xmission.com> 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 <ebiederm@xmission.com>
>>> ---
>>>  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
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] umount.2: Correct the description of MNT_DETACH

[Michael Kerrisk (man-pages)]

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
> <ebiederm@xmission.com> wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>
>>> On Mon, Sep 29, 2014 at 6:04 PM, Eric W. Biederman
>>> <ebiederm@xmission.com> 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 <ebiederm@xmission.com>
>>>> ---
>>>>  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/

Re: [PATCH] umount.2: Correct the description of MNT_DETACH

[Eric W. Biederman]

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> 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

[PATCH] umount.2: Document the effect of shared subtrees on umount

[Eric W. Biederman]

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 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

Re: [PATCH] umount.2: Document the effect of shared subtrees on umount

[Michael Kerrisk (man-pages)]

On 10/28/2014 06:33 PM, Eric W. Biederman wrote:
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

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/

Re: [PATCH] umount.2: Correct the description of MNT_DETACH

[Michael Kerrisk (man-pages)]

On 09/30/2014 03:04 AM, Eric W. Biederman 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.

Thanks, Eric, and sorry for the delay. I've
applied this now.

Cheers,

Michael


> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> ---
>  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.
>  .TP
>  .BR MNT_EXPIRE " (since Linux 2.6.8)"
>  Mark the mount point as expired.
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/