linux-kernel - SVr4/SVID/SUS IPC conformance

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 for Android: free password hash cracker in your pocket

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

Message-ID: <h8ps1mm64v.fsf@pepelac.englab.brq.redhat.com>
Date:	Fri, 17 Aug 2007 19:18:40 +0200
From:	Anton Arapov <aarapov@...hat.com>
To:	linux-kernel@...r.kernel.org
Subject: SVr4/SVID/SUS IPC conformance

Hi!

* Please, gurus, who cares about standards conformance, do not ignore this message!

  SysV code returns EIDRM for collision of IDs. I sure it should return EINVAL.

  Steps to reproduce: (this for shared memory code, for msg/sem it is the same)
   1. Create then drop 2 shmem segments, then create a third.
   2. Try to shmctl(IPC_STAT) the two now-invalid shm IDs.
   3. Note error codes returned.

   One call gives EINVAL, one gives EIDRM due to collision with the third shmem \
segment.  Should both give EINVAL, this is what I've got on every other Unix I've \
tried it on. 

  IPC code is good, EIDRM is justification of EINVAL. But neither SVr4 nor SVID \
documents EIDRM.   Single Unix Specification mentions EINVAL but not EIDRM as a \
possible failure for shmctl(), so the current kernel behavior is not merely \
self-inconsistent but a flat violation of the spec. 

  Can somebody explain why do we have EIDRM?

Anton.
SUS: http://www.opengroup.org/onlinepubs/007908799/xsh/shmctl.html
-- 
Anton Arapov, <aarapov@...hat.com>
-
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/