The opencryptoki consists of several components - the slot manager daemon (pkcsslotd), the main API library, and the cryptographic device specific plugins slot token dynamic link libraries (STDLLs). See the following for an overview: http://www.ibm.com/developerworks/linux/library/s-pkcs/ pkcsslotd manages slots and tokens in the system. When client applications wants to use any of the available cryptographic devices using the opencryptoki library, it calls library's C_Initialize API. This makes opencryptoki to attach shared memory segment managed by the pkcsslotd to get information about available tokens. The information about each token exported by pkcsslotd includes name of the STDLL library that implements support for the particular device. The opencryptoki library then loads (using dlopen) STDLL for each available device. Access to the pkcsslotd's memory requires pkcs11 group membership. However, shared memory is writeable to pkcs11 group (the library updates some portions of that shared memory, e.g. when application opens new session). Any user in the pkcs11 group can modify path to the STDLL exported for some slot/token, which may lead to an execution of arbitrary code with the privileges of some other user using opencryptoki (possibly root user).
According to upstream, this is not a security problem. All pkcs11 group members are assumed to be trusted and within the same trust boundary. I have filed bug #730903 to see if we can improve the documentation provided with opencryptoki packages to warn about additional privileges granted with pkcs11 group membership.