Back to Operating Systems Home Page

Re: SysV IPC question

The topic of this message will be among the subjects of this week's
tutorials, so I thought to broadcast to everyone my reply to Mark. 

On Wed, 4 Mar 1998, Mark Aran Aiken wrote:

[ Two possible ways to create an IPC resource ]

>     1- Calling *get with a key parameter of IPC_PRIVATE, thereby
> creating a new resource, noting the identifier of the new resource,
> and fork()ing. This requires that the collaborating processes be
> parent and child, but you are guranteed to get a brand-new IPC
> resource.

Correct
 
>     2- Calling *get with a key parameter set to some pre-agreed-on
> key, and passing IPC_CREAT as a flag. The first collaborating process
> to make the call will create the resource, and the second (and
> subsequent) ones will get back the identifier of the pre-existing
> resource.
> 
>     #1 seems fine, but is Is #2 kocher? The problem is that some
> other, unrelated, process may be running on the same machine could
> have randomly chosen the same key number, right? Processes could go
> looking for a shared IPC resource using a certain "pre-agreed-upon"
> key value, and wind up with an IPC resource created by an unrelated
> process for an unrelated purpose, and wreak havoc with it!
>
>     What's the official word on this problem?

Yes, it's a problem (i.e. an official pile of curd: unix doesn't have
many of those, but some sneaked in ;-).

The SysV "committee" designers who made the IPCs first thought one didn't
need a name in the file system to make something useful, then realized the
flop, and come with ftok(3) to save their sorry bums. 

The idea is that related processes agree on a filename, which is made
"invisible" to the rest of the world by setting appropriately the
permission bits of the directory that contains it. Then ftok(3) is used to
turn the name into a key (it's just a dumb hashing function, but it's
sparse enough that it's unlikely that different names give the same key).
It's better than nothing, but the obvious problem with it is that the
user-group-world mechanism for file access authorization in UNIX is often
not flexible enough to give the kind of control needed by an application -
you end up having to create lots of user groups just fro the purpose of
making some applications work.

Cheers
Franco

P.S. As an Olivetti spokesman said in 1991, "explaining" why they couldn't
synch the audio and the video signals of their new computer video editing
system: "Oh, we are marketing it as an educational aid for the hearing
impaired, thereby audio synch is no concern".