manpage regarding shmat after deleting a segment

manpage regarding shmat after deleting a segment

[Davidlohr Bueso]

Hi Michael,

We currently have the following statement in the shmctl(2) manpage:

      Linux permits a process to attach (shmat(2)) a shared memory segment
      that has already been marked for deletion using shmctl(IPC_RMID).
      This feature is  not  available  on other UNIX implementations;
      portable applications should avoid relying on it.

Which seems to be incorrect, or at least confusing/stale. shmat() will
check against previously deleted segments (although the resources are in
fact deleted only when the last process referencing it exits). Therefore
Linux appears to do what all other Unices do.

Specifically, this is in the form of validating against ipc_valid_object(),
which checks against the deleted flag, returning EIDRM when the segment has
already been marked for deletion via shmctl(IPC_RMID).

Now, previously shmat() used to check against shm_file validity (changed in
0f3d2b0135f4 ipc: introduce ipc_valid_object() helper to sort out IPC_RMID
races), which is basically the same wrt to the text in question. So this
behavior is in fact quite old. Furthermore, in general there seems to be a
lot of ambiguity among IPC_RMID, EIDRM, EINVAL, and now this text.

Therefore I propose dropping this. Am I missing something? Thoughts?

Thanks,
Davidlohr

diff --git a/man2/shmctl.2 b/man2/shmctl.2
index 21ede49..72a2854 100644
--- a/man2/shmctl.2
+++ b/man2/shmctl.2
@@ -405,14 +405,6 @@ In the future, these may modified or moved to a
  .I /proc
  filesystem interface.
  
-Linux permits a process to attach
-.RB ( shmat (2))
-a shared memory segment that has already been marked for deletion
-using
-.IR shmctl(IPC_RMID) .
-This feature is not available on other UNIX implementations;
-portable applications should avoid relying on it.
-
  Various fields in a \fIstruct shmid_ds\fP were typed as
  .I short
  under Linux 2.2

Re: manpage regarding shmat after deleting a segment

[Davidlohr Bueso]

On Mon, 12 Oct 2015, Bueso wrote:

>Hi Michael,
>
>We currently have the following statement in the shmctl(2) manpage:
>
>     Linux permits a process to attach (shmat(2)) a shared memory segment
>     that has already been marked for deletion using shmctl(IPC_RMID).
>     This feature is  not  available  on other UNIX implementations;
>     portable applications should avoid relying on it.
>
>Which seems to be incorrect, or at least confusing/stale. shmat() will
>check against previously deleted segments (although the resources are in
>fact deleted only when the last process referencing it exits). Therefore
>Linux appears to do what all other Unices do.

Ok, so perhaps not so stale. Its just that we managed to break userspace
again via a399b29dfba (ipc,shm: fix shm_file deletion races), which is
something we need to proporly do the the lockless ipc object lookups/security
checks. Sure, without that 'if (shp->shm_file == NULL)' check, there is
no problem with attaching to a deleted seg.

At this point, the manpage should probably be updated to indicate that
this behavior is only as of v3.10.

>
>Specifically, this is in the form of validating against ipc_valid_object(),
>which checks against the deleted flag, returning EIDRM when the segment has
>already been marked for deletion via shmctl(IPC_RMID).
>
>Now, previously shmat() used to check against shm_file validity (changed in
>0f3d2b0135f4 ipc: introduce ipc_valid_object() helper to sort out IPC_RMID
>races), which is basically the same wrt to the text in question. So this
>behavior is in fact quite old. Furthermore, in general there seems to be a
>lot of ambiguity among IPC_RMID, EIDRM, EINVAL, and now this text.
>
>Therefore I propose dropping this. Am I missing something? Thoughts?
>
>Thanks,
>Davidlohr
>
>diff --git a/man2/shmctl.2 b/man2/shmctl.2
>index 21ede49..72a2854 100644
>--- a/man2/shmctl.2
>+++ b/man2/shmctl.2
>@@ -405,14 +405,6 @@ In the future, these may modified or moved to a
> .I /proc
> filesystem interface.
>-Linux permits a process to attach
>-.RB ( shmat (2))
>-a shared memory segment that has already been marked for deletion
>-using
>-.IR shmctl(IPC_RMID) .
>-This feature is not available on other UNIX implementations;
>-portable applications should avoid relying on it.
>-
> Various fields in a \fIstruct shmid_ds\fP were typed as
> .I short
> under Linux 2.2

Re: manpage regarding shmat after deleting a segment

[Davidlohr Bueso]

On Mon, 12 Oct 2015, Bueso wrote:
>At this point, the manpage should probably be updated to indicate that
>this behavior is only as of v3.10.

Something like this, perhaps?

8<----------------------------------------------------------------------
From: Davidlohr Bueso <dave@stgolabs.net>
Date: Mon, 12 Oct 2015 12:40:53 -0700
Subject: [PATCH] shm: Document Linux policies for reusing removed segments

With a399b29dfba (ipc,shm: fix shm_file deletion races) we
changed the policy on how we deal with segments which are
marked for deletion. This is an unintended consequence of
the previous lockless ipc object lookup and security checks.

Update the corresponding man-page to reflect this new behavior

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
  man2/shmctl.2 |  6 ++++--
  man2/shmop.2  | 10 ++++++----
  2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/man2/shmctl.2 b/man2/shmctl.2
index 21ede49..6212aa4 100644
--- a/man2/shmctl.2
+++ b/man2/shmctl.2
@@ -405,13 +405,15 @@ In the future, these may modified or moved to a
  .I /proc
  filesystem interface.
  
-Linux permits a process to attach
+Until version 3.9, Linux permits a process to attach
  .RB ( shmat (2))
  a shared memory segment that has already been marked for deletion
  using
  .IR shmctl(IPC_RMID) .
  This feature is not available on other UNIX implementations;
-portable applications should avoid relying on it.
+portable applications should avoid relying on it. As of version
+3.10, -EIDRM will be returned in these scenarios, and therefore
+attaching to a deleted segment is considered forbidden.
  
  Various fields in a \fIstruct shmid_ds\fP were typed as
  .I short
diff --git a/man2/shmop.2 b/man2/shmop.2
index e818796..1ea6f99 100644
--- a/man2/shmop.2
+++ b/man2/shmop.2
@@ -266,10 +266,12 @@ Therefore, any pointers maintained within the shared memory must be
  made relative (typically to the starting address of the segment),
  rather than absolute.
  .PP
-On Linux, it is possible to attach a shared memory segment even if it
-is already marked to be deleted.
-However, POSIX.1 does not specify this behavior and
-many other implementations do not support it.
+Up until version 3.9 On Linux, it is possible to attach a shared
+memory segment even if it is already marked to be deleted. However,
+POSIX.1 does not specify this behavior and many other implementations
+do not support it. As of version 3.10, -EIDRM will be returned in
+these scenarios, and therefore attaching to a deleted segment is
+considered forbidden.
  .LP
  The following system parameter affects
  .BR shmat ():
-- 
2.1.4

Re: manpage regarding shmat after deleting a segment

[Davidlohr Bueso]

On Mon, 12 Oct 2015, Bueso wrote:
>Something like this, perhaps?

ping?

Re: manpage regarding shmat after deleting a segment

[Michael Kerrisk]

Hi David,

On Mon, Oct 12, 2015 at 9:43 PM, Davidlohr Bueso <dave@stgolabs.net> wrote:
> On Mon, 12 Oct 2015, Bueso wrote:
>>
>> At this point, the manpage should probably be updated to indicate that
>> this behavior is only as of v3.10.
>
>
> Something like this, perhaps?

Either I am misunderstanding you, or you're misunderstanding the man
page, I believe. The scenario I'm talking about is something like this

Process A              Process B

id = shmget(key, size, flags);
                       id = shmget(key, size, flags);
                       /* Or get the ID by some other means */
addr = shmat(id, addr, flags);
shmctl(id, IPC_RMID, 0);
                        addr = shmat(id, addr, flags);
                        /* Succeeds on Linux, but not on other systems */

I just tested this on a 3.19 kernel, and it still holds true. Have I
misunderstood your point?

Cheers,

Michael


> 8<----------------------------------------------------------------------
> From: Davidlohr Bueso <dave@stgolabs.net>
> Date: Mon, 12 Oct 2015 12:40:53 -0700
> Subject: [PATCH] shm: Document Linux policies for reusing removed segments
>
> With a399b29dfba (ipc,shm: fix shm_file deletion races) we
> changed the policy on how we deal with segments which are
> marked for deletion. This is an unintended consequence of
> the previous lockless ipc object lookup and security checks.
>
> Update the corresponding man-page to reflect this new behavior
>
> Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
> ---
>  man2/shmctl.2 |  6 ++++--
>  man2/shmop.2  | 10 ++++++----
>  2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/man2/shmctl.2 b/man2/shmctl.2
> index 21ede49..6212aa4 100644
> --- a/man2/shmctl.2
> +++ b/man2/shmctl.2
> @@ -405,13 +405,15 @@ In the future, these may modified or moved to a
>  .I /proc
>  filesystem interface.
>  -Linux permits a process to attach
> +Until version 3.9, Linux permits a process to attach
>  .RB ( shmat (2))
>  a shared memory segment that has already been marked for deletion
>  using
>  .IR shmctl(IPC_RMID) .
>  This feature is not available on other UNIX implementations;
> -portable applications should avoid relying on it.
> +portable applications should avoid relying on it. As of version
> +3.10, -EIDRM will be returned in these scenarios, and therefore
> +attaching to a deleted segment is considered forbidden.
>   Various fields in a \fIstruct shmid_ds\fP were typed as
>  .I short
> diff --git a/man2/shmop.2 b/man2/shmop.2
> index e818796..1ea6f99 100644
> --- a/man2/shmop.2
> +++ b/man2/shmop.2
> @@ -266,10 +266,12 @@ Therefore, any pointers maintained within the shared
> memory must be
>  made relative (typically to the starting address of the segment),
>  rather than absolute.
>  .PP
> -On Linux, it is possible to attach a shared memory segment even if it
> -is already marked to be deleted.
> -However, POSIX.1 does not specify this behavior and
> -many other implementations do not support it.
> +Up until version 3.9 On Linux, it is possible to attach a shared
> +memory segment even if it is already marked to be deleted. However,
> +POSIX.1 does not specify this behavior and many other implementations
> +do not support it. As of version 3.10, -EIDRM will be returned in
> +these scenarios, and therefore attaching to a deleted segment is
> +considered forbidden.
>  .LP
>  The following system parameter affects
>  .BR shmat ():
> --
> 2.1.4
>
>
> --
> 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/



-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/