#22 Alternatives to using a hard-coded pathname for ftok()

[Dave Heller]

Referencing 3579637: SFCB uses the hard-coded path SFCB_BINARY as a "seed" to the ftok() function used to create semaphore keys, where SFCB_BINARY is a path determined at compile time. If this path does not exist on the system at runtime, as may happen if the prefix used for SFCB installation differs from the prefix used during build, ftok() will return an error.

The ftok() function is used to create a unique System V IPC key for use with semget(), etc. While ftok() is not an ideal solution, none of the alternatives seem to be ideal either. In place of ftok() one could use a random number generator to create the key; there would be a chance of collision, albeit a small one. But this is a non-standard approach to the problem.

Sticking with ftok(), here are some alternatives to using a hard-coded pathname:

1. Find the path of the currently running executable rather than relying on a path determined at compile time: This is an attractive solution but has the challenge that there is no single way to do this in a cross-platform compatible manner. It would require an algorithm something like (not necessarily in this order): a) check /proc filesystem, for OS that support /proc; b) check argv[0], which in not completely reliable for reasons documented elsewhere, including the need to convert a relative path to absolute path as necessary; c) check other OS-specific data structures.

2. Use a path from sfcb.cfg, such as registrationDir: The path is "guaranteed" to exist in the sense that if it does not exist SFCB could not run anyway.

Additional challenges: any solution must handle a DLO such as sfcCertificateAuthentication.c, and the stand-alone utility sfcbsem.c, which also use ftok(). In the case of sfcCertificateAuthentication the semaphore key does not have to match the value used anywhere else in SFCB, so a variation of 1. above is viable Solution 2. is not attractive since these DLO modules do not typically access the config file. However, one could modify the DLO interface to pass some pathname determined elsewhere in the code.

For sfcbsem, this program expects the semaphore keys to match those used by the runing instance of SFCB. If a hard-coded path is not used, there would need to be some way for sfcbsem to determine the key values, e.g. a temp file or some other form of IPC, or a value passed on the command line.

In sum: while the current approach of using SFCB_BINARY is not ideal, it has the virtue of simplicity; it handles all the above requirements with a minimum of code.

Finally, it should be noted that the above problem (i.e. ftok failure due to mismatch in build-time vs. runtime paths) can be worked around by simply "touching" the file that ftok is expecting to exist, where the filename is ${exec_prefix}/sbin/sfcbd.

[Chris Buccella]

Ticket moved from /p/sblim/bugs/2554/

Can't be converted:

• _component: sfcb
• _milestone: Stability
• _priority: 5