Newer GCC versions report errors for string initialization where the
terminating NULL character does not fit into the target variable.
All the fixed places use non-zero-terminated strings, but add an additional
character to make the compiler happy.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Fix various places where GCC 14 reports type inconsistencies with the size_t
and CK_ULONG (unsigned long) types.
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>
Create the unix sockets and the PID file in /run/opencryptoki, and make
sure the /run/opencryptoki directory as well as the lock and log directories
are created during 'make install' as well as during system startup via
tmpfiles.d. Since the /run directory usually is within a tmpfs file system,
it won't exist after a system restart otherwise.
Also make the /run/opencryptoki directory be owned by the 'pkcsslotd' user
and the 'pkcs11' group, and only writable by the 'pkcsslotd' user.
That way, pkcsslotd can only be started by the 'pkcsslotd' user (or root).
Nevertheless, members of the 'pkcs11' group can still connect to the sockets,
and thus can still communicate with pkcsslotd.
The 'pkcsslotd' user is created (if not already existent) during 'make install'
and RPM installation, together with the 'pkcs11' group.
When the pkcsslotd is started as 'root', change its uid to 'pkcsslotd' to drop
privileges and capabilities. Any capabilities set on the executable file
are retained, regardless if started as root or as pkcsslotd user.
If started as root, pkcsslotd can create any missing base directories, otherwise
an error is reported. It is expected that the base directories have been created
during package installation and/or tmpfiles.d prior to starting pkcsslotd.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
When running within a pid and/or user namespace, make sure to register
the process in pkcsslotd's shared memory segment using the pid from the
root namespace (the one pkcsslotd is running in), and not the applications
namespace. The application pid may be different to its pid in the root
namespace, and may especially be not unique within the root name space.
Since the pid is used as unique identifier in pkcsslotd's shared memory
segment we must use the applications pid in the root namespace.
Also use the uid from root namespace to create the shared memory segment
for user statistics. The uid in the applications namesapce may be different
to its uid in the root namespace, and may especially be not unique within
the root name space, and thus could cause that statistics of other users are
updated instead of the current user's one.
Trace files are still named using the pid of the applications namespace.
At the time the trace file is opened, the pid from the root namespace is
not yet know. There is a is a slight chance that two processes running in
different namespaces use the same pid, and thus use the same trace file.
In this case existing trace files may get overwritten or tracing is
disabled for a process. Re-opening the trace file once the process's pid
from the root namespace is known does not make much sense, since the
initial part of the trace has been written to the 'wrong' trace file
already at that time.
Since the initial data sent via socket is changed anyway, fix the following
issue right away:
Closes: https://github.com/opencryptoki/opencryptoki/issues/469
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Avoid that the event thread writes trace messages while it is
enabled for thread cancellation. This might leave the trace mutex in
the locked state and cause subsequent trace calls to lock forever
(e.g in stop_event_thread() right after canceling the thread).
Disable cancellation right at the beginning of the thread function,
and disable it before calling a trace function or leaving the loop.
Also make sure that the cleanup handler is registered and the
cancellation type is set before initially enabling cancellation.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Create a separate library context for Opencryptoki's use of OpenSSL services
and explicitly load the 'default' provider for this context.
This prevents call-loops when the calling application has configured a PKCS#11
provider that uses Opencryptoki under the covers. This could produce a loop
with the following calling tree:
Application -> Openssl -> PKCS11-provider -> Opencryptoki -> OpenSSL
-> PKCS11-provider -> Opencryptoki -> ...
Explicitly using the 'default' provider only for Opencrypoki's OpenSSL usage
breaks this loop.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
