linux-kernel - Re: manpage regarding shmat after deleting a segment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151012194329.GE3170@linux-uzut.site>
Date:	Mon, 12 Oct 2015 12:43:29 -0700
From:	Davidlohr Bueso <dave@...olabs.net>
To:	Michael Kerrisk <mtk@...7.org>
Cc:	linux-kernel@...r.kernel.org, Greg Thelen <gthelen@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: manpage regarding shmat after deleting a segment

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