clarification required on .camlcrushlibname usage and request for more dynamic client configuration

[FrankHomeSend]

Contrary to the previous behaviour with the --with-libnames configure parameter, the newly added runtime configuration of the pkcs11 module identifier allows for more dynamic usage of the same client library for different backend PKCS #11 modules exposed by a caml-crush server daemon.

However, it's not entirely clear where the .camlcrushlibname file should be located; in my use case, I'd like service accounts that are running processes (e.g. apache) access the caml-crush client library. These accounts do not have home directories, and the processes they run are usually started from init.d or systemd scripts.

Another thing to think about in this scenario, is that the server hostname/IP and port number have been hardcoded into the client library.

As an alternative to the current behaviour, would it be an idea to add an option to compile a client library with a hardcoded path to a configuration file (e.g. '/etc/pkcs11/camlcrush_apache.conf' for a hypothetical 'libp11client-apache.so' client module, which uses parameters read from this configuration file to initialise:

• PKCS #11 module identifier (the current intended usage of .camlcrushlibname)
• caml-crush proxy server hostname or IP address + port number
• path to client identity certificate and private key
• path to Certificate Authority certificate used to validate own identity and server identity

This way, multiple client libraries can be compiled with different hardcoded configuration file paths that can be used concurrently on the same client machines, each being fully flexible in which caml-crush server, port, pkcs11 module identifier and which certificates are used for secure communication.

Regards,
Frank

[tc-anssi]

Hi,

The .camlcrushlibname file location is derived from the HOME environment variable.
In standard configuration, Apache owns /var/www as its home directory, hence the file could be placed there.
Now, I agree that this might not be enough in some scenarios.

However, you can always override the compile time parameters using environment variables (not thoroughly documented ...).
Those are:

• PKCS11PROXY_SOCKET_PATH (Unix socket path, IP or DNS name)
• PKCS11PROXY_LIBNAME (module alias)
• PKCS11PROXY_RPC_TIMEOUT (seconds before RPC timeout)
• PKCS11PROXY_CA_FILE (path to CA file)
• PKCS11PROXY_CERT_FILE (path to cert file)
• PKCS11PROXY_PRIVKEY_FILE (path to priv key file)

This should provide enough flexibility in most use cases.
Using a dedicated configuration file whose location can be defined at compilation is an alternative, but it requires adding some code to handle the parsing, thus introducing potential parsing errors, etc.

In any case contributions are welcome.

Cheers,

Thomas

[FrankHomeSend]

thanks for the pointer; these environment variables will probably be sufficient for the use case I'm studying.