Ambiguity in SysV IPC keys

[Roy Smith]

In SysV IPC, when you call ftok() to get a key, the key is not
guaranteed to be unique. How do people code around this potential key
ambiguity in real life? Do you just count on the probability of a key
collission being very low and pretend it'll never happen?

[Kurtis D. Rader]

On Sat, 19 Jul 2003 14:33:44 +0000, Roy Smith wrote:

> In SysV IPC, when you call ftok() to get a key, the key is not guaranteed
> to be unique. How do people code around this potential key ambiguity in
> real life? Do you just count on the probability of a key collission
> being very low

Yes

> and pretend it'll never happen?

No. You should still code defensively. Simply performing normal sanity
checks and refusing to continue if the expected conditions are not
present is often appropriate and sufficient. For example, validate
that the owner and permissions on the segment make sense before using
its contents. Stick a "signature" in the segment and validate that.
If those sanity checks fail provide the option of using a different
pathname for the ftok() function or allow the key to be specified
directly. However, given the very low probability of a ftok() key
collision it isn't worth performing any action other than those you
would normally perform even if you were guaranteed a globally unique key.

[Marc Rochkind]

On Sat, 19 Jul 2003 14:33:44 -0400, Roy Smith <roy@panix.com> wrote:

> In SysV IPC, when you call ftok() to get a key, the key is not guaranteed
> to be unique.

[snip]

The Single UNIX Specification v. 3:

"The ftok() function shall return the same key value for all paths that
name the same file, when called with the same id value, and return
different key values when called with different id values or with paths
that name different files existing on the same file system at the same
time. It is unspecified whether ftok() shall return the same key value when
called again after the file named by path is removed and recreated with the
same name."

So, it seems to me that a solution is to follow the rule that the paths
must all be in the same file system. For example, all of the form
"/etc/SysVIPC/xyz" where xyz varies.

Am I missing something?

It is true that someone who knows nothing of the rule but is using the same
system could come up with the same key, but presumambly the permissions
would prevent such a person from doing anything with a SysV IPC object
obtained with the key.

--Marc

[Marc Rochkind]

On Sun, 20 Jul 2003 11:59:01 +0000, Bjorn Reese <breese@mail1.stofanet.dk>
wrote:

[snip]

>
> Two different paths may map into the same hash value.
>

But not on the same file system. That's why a convention that paths be in
the same directory sorts things out.

--Marc

[Roy Smith]

Marc Rochkind <rochkind@basepath.com> wrote:

> But not on the same file system.

My understanding is that's not guaranteed.

> That's why a convention that paths be in
> the same directory sorts things out.

The same directory as what? I write a program which uses IPC, and you
do the same. What directory are we supposed to use in common?

[Marc Rochkind]

On Sun, 20 Jul 2003 13:26:22 -0400, Roy Smith <roy@panix.com> wrote:

> Marc Rochkind <rochkind@basepath.com> wrote:

>> But not on the same file system.

>
> My understanding is that's not guaranteed.
>

>> That's why a convention that paths be in the same directory sorts things
>> out.

>
> The same directory as what? I write a program which uses IPC, and you do
> the same. What directory are we supposed to use in common?
>

See my earlier msg in this thread...

The guarantee is in the SUS (quoted in my earlier msg). The convention I
suggested is that there be a common directory on each system.

--Marc

[Michael Kerrisk]

On Sun, 20 Jul 2003 12:29:15 -0600, Marc Rochkind
<rochkind@basepath.com> wrote:

>On Sun, 20 Jul 2003 13:26:22 -0400, Roy Smith <roy@panix.com> wrote:
>

>> Marc Rochkind <rochkind@basepath.com> wrote:

>>> But not on the same file system.

>>
>> My understanding is that's not guaranteed.
>>

>>> That's why a convention that paths be in the same directory sorts things
>>> out.

>>
>> The same directory as what? I write a program which uses IPC, and you do
>> the same. What directory are we supposed to use in common?
>>

>
>
>See my earlier msg in this thread...
>
>The guarantee is in the SUS (quoted in my earlier msg). The convention I
>suggested is that there be a common directory on each system.

I haven't checked over the SUSv3 wording, but I don't think that most
implementations would gauantee uniqueness following your convention
Marc. A typical implementation use just the lowest 16 bytes of the
i-node number, rather than the whole number, so there is clealrly the
possibility for two paths to generate the same key from ftok().

Cheers

Michael

[Michael Kerrisk]

On Sat, 19 Jul 2003 13:20:21 -0700, "Kurtis D. Rader"
<krader@skepticism.us> wrote:

>On Sat, 19 Jul 2003 14:33:44 +0000, Roy Smith wrote:
>

>> In SysV IPC, when you call ftok() to get a key, the key is not guaranteed
>> to be unique. How do people code around this potential key ambiguity in
>> real life? Do you just count on the probability of a key collission
>> being very low

>
>Yes
>

>> and pretend it'll never happen?

>
>No. You should still code defensively. Simply performing normal sanity
>checks and refusing to continue if the expected conditions are not
>present is often appropriate and sufficient. For example, validate
>that the owner and permissions on the segment make sense before using
>its contents. Stick a "signature" in the segment and validate that.

(Minor quibble: a signature isn't possible with semaphores or message
queues.)

>If those sanity checks fail provide the option of using a different
>pathname for the ftok() function or allow the key to be specified
>directly. However, given the very low probability of a ftok() key
>collision it isn't worth performing any action other than those you
>would normally perform even if you were guaranteed a globally unique key.

Another possibility to consider: abandon ftok() altogether. Use the
IPC_PRIVATE key to create the object and then write the object
identifier to a file which is read by all other applications requiring
access to the object.

Cheers,

Michael

[Roy Smith]

In article <ei3nhv0ac4bsticebbdinlcsffkgkfbh38@4ax.com>,
Michael Kerrisk <michael.kerrisk@freenet.de> wrote:

> Another possibility to consider: abandon ftok() altogether. Use the
> IPC_PRIVATE key to create the object and then write the object
> identifier to a file which is read by all other applications requiring
> access to the object.

I like this idea a lot. Seems like it would also solve a lot of the
semaphore race conditions Stevens talks about.

[Dragan Cvetkovic]

Marc Rochkind <rochkind@basepath.com> writes:

> On Sun, 20 Jul 2003 13:26:22 -0400, Roy Smith <roy@panix.com> wrote:
>

> > Marc Rochkind <rochkind@basepath.com> wrote:

> >> But not on the same file system.

> >
> > My understanding is that's not guaranteed.
> >

> >> That's why a convention that paths be in the same directory sorts things
> >> out.

> >
> > The same directory as what? I write a program which uses IPC, and you do
> > the same. What directory are we supposed to use in common?
> >

>
>
> See my earlier msg in this thread...
>
> The guarantee is in the SUS (quoted in my earlier msg). The convention I
> suggested is that there be a common directory on each system.
>

Like lost+found :-) ?

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!

[Larry Blanchard]

In article <ei3nhv0ac4bsticebbdinlcsffkgkfbh38@4ax.com>,
[email]michael.kerrisk@freenet.de[/email] says...

> Another possibility to consider: abandon ftok() altogether. Use the
> IPC_PRIVATE key to create the object and then write the object
> identifier to a file which is read by all other applications requiring
> access to the object.
>
>

Works great. Another possibility, if you have cooperating tasks, is just
to predefine the keys in an include file.

--
Where ARE those Iraqi WMDs?

[Eric Sosman]

Larry Blanchard wrote:

>
> In article <ei3nhv0ac4bsticebbdinlcsffkgkfbh38@4ax.com>,
> [email]michael.kerrisk@freenet.de[/email] says...

> > Another possibility to consider: abandon ftok() altogether. Use the
> > IPC_PRIVATE key to create the object and then write the object
> > identifier to a file which is read by all other applications requiring
> > access to the object.
> >
> >

> Works great. Another possibility, if you have cooperating tasks, is just
> to predefine the keys in an include file.

... and hope that no other application happens to use the
same keys. One "other application" that's particularly likely
to do so is a second instance of the same program.

--
[email]Eric.Sosman@sun.com[/email]

[Michael Kerrisk]

On Mon, 21 Jul 2003 08:03:22 -0400, Roy Smith <roy@panix.com> wrote:

>In article <ei3nhv0ac4bsticebbdinlcsffkgkfbh38@4ax.com>,
> Michael Kerrisk <michael.kerrisk@freenet.de> wrote:
>

>> Another possibility to consider: abandon ftok() altogether. Use the
>> IPC_PRIVATE key to create the object and then write the object
>> identifier to a file which is read by all other applications requiring
>> access to the object.

>
>I like this idea a lot. Seems like it would also solve a lot of the
>semaphore race conditions Stevens talks about.

No -- I don't think this really helps you with the race condition, but
it is tangentially related: one thing that you need to be aware ofis
that Stevens's solution to the race is not needed in all cases. If
one process can be guaranteed (by other means) to be the first to
create and initialize the semaphore set, then this can simply be done
using a single calls to semget() and semop(). If your application is
one where the IPC_PRIVATE technique can be applied, then probably also
you create/initialize in this simple way.

The solution given by Steven's is needed when there are multiple
*peer* processes, that is, any one of a number of (i.e., two or more)
processes may be the one to create and initalize the semaphore. If
this is the case, then it's also likely that the IPC_PRIVATE technique
will at least take a bit more effort to be workable (since any of the
peers may be the one to create the file used to record the semaphore
ID).

Cheers

Michael

[Larry Blanchard]

In article <3F1C15AB.8F159CB9@sun.com>, [email]Eric.Sosman@sun.com[/email] says...

> Larry Blanchard wrote:

> >

> > >

> > Works great. Another possibility, if you have cooperating tasks, is just
> > to predefine the keys in an include file.

>
> ... and hope that no other application happens to use the
> same keys. One "other application" that's particularly likely
> to do so is a second instance of the same program.
>

I said "cooperating", didn't I? The applications I've used this in were
all dedicated process control and/or data acquisition systems :-).

--
Where ARE those Iraqi WMDs?

[Larry Blanchard]

In article <3F1D60CA.A3B5E5B9@sun.com>, [email]Eric.Sosman@sun.com[/email] says...

> Larry Blanchard wrote:

> >
> > I said "cooperating", didn't I? The applications I've used this in were
> > all dedicated process control and/or data acquisition systems :-).

>
> Ah, a difference in viewpoint. I've been burned far
> too often by applications originally written for single-
> user systems and then ported to multi-user systems.
>

Oh these were multi-user. It's just that the users were factory floor
folks and they don't write programs :-).

--
Where ARE those Iraqi WMDs?