* [PATCH] umount.2: Correct the description of MNT_DETACH
@ 2014-09-30 1:04 Eric W. Biederman
2014-09-30 1:28 ` Andy Lutomirski
2015-02-02 15:34 ` [PATCH] umount.2: Correct the description of MNT_DETACH Michael Kerrisk (man-pages)
0 siblings, 2 replies; 9+ messages in thread
From: Eric W. Biederman @ 2014-09-30 1:04 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Andy Lutomirski, Andrey Wagin, linux-fsdevel, Al Viro, linux-kernel
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] umount.2: Correct the description of MNT_DETACH
2014-09-30 1:04 [PATCH] umount.2: Correct the description of MNT_DETACH Eric W. Biederman
@ 2014-09-30 1:28 ` Andy Lutomirski
2014-09-30 2:15 ` Eric W. Biederman
2015-02-02 15:34 ` [PATCH] umount.2: Correct the description of MNT_DETACH Michael Kerrisk (man-pages)
1 sibling, 1 reply; 9+ messages in thread
From: Andy Lutomirski @ 2014-09-30 1:28 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Michael Kerrisk, Andrey Wagin, Linux FS Devel, Al Viro, linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] umount.2: Correct the description of MNT_DETACH
2014-09-30 1:28 ` Andy Lutomirski
@ 2014-09-30 2:15 ` Eric W. Biederman
2014-09-30 2:16 ` Andy Lutomirski
0 siblings, 1 reply; 9+ messages in thread
From: Eric W. Biederman @ 2014-09-30 2:15 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Michael Kerrisk, Andrey Wagin, Linux FS Devel, Al Viro, linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] umount.2: Correct the description of MNT_DETACH
2014-09-30 2:15 ` Eric W. Biederman
@ 2014-09-30 2:16 ` Andy Lutomirski
2014-10-28 13:43 ` Michael Kerrisk (man-pages)
0 siblings, 1 reply; 9+ messages in thread
From: Andy Lutomirski @ 2014-09-30 2:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Michael Kerrisk, Andrey Wagin, Linux FS Devel, Al Viro, linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] umount.2: Correct the description of MNT_DETACH
2014-09-30 2:16 ` Andy Lutomirski
@ 2014-10-28 13:43 ` Michael Kerrisk (man-pages)
2014-10-28 17:31 ` Eric W. Biederman
0 siblings, 1 reply; 9+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-10-28 13:43 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Andy Lutomirski, mtk.manpages, Andrey Wagin, Linux FS Devel,
Al Viro, linux-kernel
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] umount.2: Correct the description of MNT_DETACH
2014-10-28 13:43 ` Michael Kerrisk (man-pages)
@ 2014-10-28 17:31 ` Eric W. Biederman
2014-10-28 17:33 ` [PATCH] umount.2: Document the effect of shared subtrees on umount Eric W. Biederman
0 siblings, 1 reply; 9+ messages in thread
From: Eric W. Biederman @ 2014-10-28 17:31 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Andy Lutomirski, Andrey Wagin, Linux FS Devel, Al Viro, linux-kernel
"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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] umount.2: Document the effect of shared subtrees on umount
2014-10-28 17:31 ` Eric W. Biederman
@ 2014-10-28 17:33 ` Eric W. Biederman
2015-02-02 15:36 ` Michael Kerrisk (man-pages)
0 siblings, 1 reply; 9+ messages in thread
From: Eric W. Biederman @ 2014-10-28 17:33 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Andy Lutomirski, Andrey Wagin, Linux FS Devel, Al Viro, linux-kernel
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] umount.2: Correct the description of MNT_DETACH
2014-09-30 1:04 [PATCH] umount.2: Correct the description of MNT_DETACH Eric W. Biederman
2014-09-30 1:28 ` Andy Lutomirski
@ 2015-02-02 15:34 ` Michael Kerrisk (man-pages)
1 sibling, 0 replies; 9+ messages in thread
From: Michael Kerrisk (man-pages) @ 2015-02-02 15:34 UTC (permalink / raw)
To: Eric W. Biederman
Cc: mtk.manpages, Andy Lutomirski, Andrey Wagin, linux-fsdevel,
Al Viro, linux-kernel
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] umount.2: Document the effect of shared subtrees on umount
2014-10-28 17:33 ` [PATCH] umount.2: Document the effect of shared subtrees on umount Eric W. Biederman
@ 2015-02-02 15:36 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 9+ messages in thread
From: Michael Kerrisk (man-pages) @ 2015-02-02 15:36 UTC (permalink / raw)
To: Eric W. Biederman
Cc: mtk.manpages, Andy Lutomirski, Andrey Wagin, Linux FS Devel,
Al Viro, linux-kernel
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-02-02 15:36 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-30 1:04 [PATCH] umount.2: Correct the description of MNT_DETACH Eric W. Biederman
2014-09-30 1:28 ` Andy Lutomirski
2014-09-30 2:15 ` Eric W. Biederman
2014-09-30 2:16 ` Andy Lutomirski
2014-10-28 13:43 ` Michael Kerrisk (man-pages)
2014-10-28 17:31 ` Eric W. Biederman
2014-10-28 17:33 ` [PATCH] umount.2: Document the effect of shared subtrees on umount Eric W. Biederman
2015-02-02 15:36 ` Michael Kerrisk (man-pages)
2015-02-02 15:34 ` [PATCH] umount.2: Correct the description of MNT_DETACH Michael Kerrisk (man-pages)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).