linux && ipc (semget, msgget, и т.д.)

IPC_PRIVATE имеет тип key_t, semget возвращает id семафора,
 то есть говорить что semget вернул IPC_PRIVATE - неправильно.
 Он вернул ид. созданного семафора, и этот ид совпал с числовым значением IPC_PRIVATE. То что у семафора id получился 0 - ну дык он-же первый созданный.(Если ненравится поставьте на ядро секурный патч который обеспечивает генерацию случайных идентификаторов.) 

 То что флаги не проверяются - тож правильно, ибо проверять нечего,
при IPC_PRIVATE должен создаваться НОВЫЙ семафор. 
(далее выдержка из man semget)

 A new set of nsems semaphores is created if key has  the
       value  IPC_PRIVATE or if no existing semaphore set is associated to key
       and IPC_CREAT is asserted in semflg (i.e.   semflg  &  IPC_CREAT  isn't
       zero).

> ...теперь в других процессах, если они знают id, они могут сделать так semget(id, ...);

Это неверно.

semget(key,...) с тем же key вернет id того же набора, если key не 0. Возвращенный id, вообще говоря, локальный по отношению к вызвавшему semget() процессу.

Вдогонку:

> Возвращенный id, вообще говоря, локальный по отношению к вызвавшему semget() процессу.

Во избежание недоразумений -- я имел в виду "логически" локальный. Он должен быть получен semget() и никак иначе.

>Он должен быть получен semget() и никак иначе.

а если id передан родителем?

> а если id передан родителем?

Дык, если родитель получил его через semget(), то все в порядке. Как с файловыми дескрипторами.

Вообще говоря, SysV IPC изначально предполагает IPC между не-родственными процессами (потому-то это и не кошерный Юникс-вэй).

И id по уму должен был бы быть действительно локальным к процессу. То есть, программы для IPC знают key (который обычно получается на основании инодов), а целочисленные id, вырабатываемые на основании этих key's, являются внутренними для процессов.

На самом деле, id глобальны в системе, что может привести к нежелательным последствиям. Например, semget(IPC_PRIVATE,..) на самом деле не приватный вовсе. Из другой программы вполне можно добраться до приватного семафора, если пермишены позволяют. Если этим не злоупотреблять, то проблем не будет (конечно, если не учитывать возможные баги).

2fghj:

Вот, посмотрел на моей машине:

------ Shared Memory Segments --------
key        shmid   owner   perms  bytes   nattch status
status
0x000219f9 0       root    666    6389    0
0x00000000 589825  devpf   600    65536   5      dest

(остально пусто).

Видно, что первый сегмент ( с id == 0, BTW!) получен от совершенно
не нулевого key, а вот второй сегмент -- приватный. Но его 
id совершенно не 0!

Никакаих проблем с перепутыванием key и shmid нет и быть не может; они,
как было замечено, даже тип разный имеют!

> SysV IPC изначально предполагает IPC между не-родственными процессами

а каким предполагалось передавать ключ в этом случае, через файл?
или все стоится на наджде что никто не выберет такой же ключ?

fghj:

man ftok

Подразумевается, что все участники IPC знают про некий файл (например, конфигурационный файл), и его инод используется для генерации key.

большое спасибо MKuznetsov Die-Hard