linux-kernel - 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-next>] [day] [month] [year] [list]

Date:	Mon, 12 Oct 2015 08:50:21 -0700
From:	Davidlohr Bueso <dave@...olabs.net>
To:	Michael Kerrisk <mtk@...7.org>
Cc:	linux-kernel@...r.kernel.org
Subject: manpage regarding shmat after deleting a segment

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
--
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/