The token shared memory segment contains an array of TOK_OBJ_ENTRY structures.
The TOK_OBJ_ENTRY structure contains an unused field 'deleted'. Remove this
to reduce the size of the array.
This reduces the size of the shared memory segment, so the sm_open() function
must be prepared to handle this size change. In case the shared memory segment
exists already, but has a lager size (i.e. from a run before this code change),
then truncate the shared memory segment and clear it. This can only be done
when no other process is currently using the shared memory segment.
Normally the very first PKCS#11 process that runs after migrating to a version
that contains this code change is the one and only process that accesses the
shared memory segment at that time. The process holds the token-lock when
sm_open() is called, so no other process can perform sm_open() at the same
time. If another process already did sm_open() then the shared memory segment
size has already been adjusted by that process.
While it at, also optimize the shared memory lookup for token objects that
already exist when a token is initialized, but the shared memory segment is
not yet populated, as well as for newly created token objects. Remember the
index of the shared memory array element inside the object when function
object_mgr_add_to_shm() adds the object to the array. That way a subsequent
object_mgr_search_shm_for_obj() will find the object quickly in the array,
unless the array has been updated by another process in the meantime.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
A new optional key value pair named 'usergroup' can be specified within a
slot structure to specify the user group name that is set as the owner of
the token directory. Only users that are members of this group have access
to the token and its objects. Users that are not a member of this group
will not see the token as being available (e.g. via 'pkcsconf -t' or via
'C_GetTokenInfo').
If no token group is specified, then the token is owned by the 'pkcs11' group
like before this change.
If a token user group is specified, then the pkcsslotd checks if that group
exists, and if all members of that group are also members of the 'pkcs11'
group. This is required to be able to access the pkcsslotd socket at all.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Allow to specify the pkcsslotd user and the pkcs11 group during
configuration.
Use '--with-pkcsslotd-user=USER' and/or '--with-pkcs-group=GROUP'
to specify the user and group name. The defaults are 'pkcsslotd'
and 'pkcs11'.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
usr/lib/common/shared_memory.c:229:9: warning: implicit declaration of function
‘OCK_SYSLOG’; did you mean ‘LOG_SYSLOG’? [-Wimplicit-function-declaration]
229 | OCK_SYSLOG(LOG_ERR,
| ^~~~~~~~~~
/usr/bin/ld:
usr/lib/common/sbin_pkcscca_pkcscca-shared_memory.o: in function `sm_open':
undefined reference to `OCK_SYSLOG'
collect2: error: ld returned 1 exit status
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The shm token segments were generated with permission 0666 for the user that
created the segment and the corresponding primary group. This is potentially
a security problem since especially the segmant was word-rw.
This patch changes the permission to 0660 and changes the ownership of the
segment on creation to group "pkcs11". Since every user that should be
allowed to use OCK has to be in that group, we should not have any usage
regressions. If the segments already exist, a reboot might be necessary (or
any other way that cleans up the segments).
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Lock C_Initialize and C_Finalize with the GlobalMutex, to prevent
multiple threads to initialize or terminate concurrently. No
further locking needed in ST_Initialize, thus remove global native_mutex.
When a child process is forked off, terminate all tokens and let them
clean up their stuff. The forked client process needs to call C_Initialize
again as per PKCS#11 standard (see PKCS #11 Cryptographic Token Interface
Usage Guide Version 2.40 section 2.5.2 Applications and Processes).
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
A new config option "tokversion = <major>.<minor>" is added to
opencryptoki.conf. This new optional key-value pair tells openCryptoki
which version of a token is associated with a slot. If the token
version is not specified explicitely, openCryptoki uses a default
version of 0.0.
If new versions of soft,ica,cca and ep11 token are set to 3.12
the new pin encryption and data store format will be used.
The 3.12 format is incompatible with the old 0.0 format i.e.,
you must not use this new format with existing data stores and
openCryptoki setups. It must only be used with fresh openCryptoki
configurations. Migration tools to migrate existing setups
to the new version will be provided in the future.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
