Add in the ability to dynamically adjust module and configuration paths at run-time via system environmental exports #442
Conversation
There was a problem hiding this comment.
There is p11_kit_override_system_files for this purpose and I remember it was a deliberate choice that we don't support setting them through envvars. Would it be possible to workaround this by either using the function or bind-mounting one of the module directories?
p11-kit/modules.c
Outdated
| */ | ||
|
|
||
| static char * | ||
| p11_kit_getenv(const char *name) |
There was a problem hiding this comment.
We can assume that secure_getenv is always defined, as common/compat.c provides the same fallback if configure/meson couldn't find it.
There was a problem hiding this comment.
Thanks -- I've removed the unnecessary check
…hs at run-time via system environmental exports Background: While trying to integrate PKCS11+HSM into a build system (Yocto Project), we wanted the build system to be able to use the HSM directly. However, The Yocto Project creates a sandboxed environment for each package which uses p11-kit during compilation. This means that the p11-kit modules and configurations cannot be found from within these sandboxed directories, as their paths are non-determinable at compile time. OpenSSL appears to use OPENSSL_CONF for this sort of dynamic configuration, so I've followed their lead and incorporated a similar p11_kit_getenv() method.
timesys-nathan
force-pushed
the
master
branch
from
c24685b to
8c2899f
Compare
|
Bind mounting or chrooting would work in theory, but it's not very compatible with how Yocto works. There's not a good way to bind mount/chroot the sandboxed build directories during the process. I did see p11_kit_override_system_files(), but that would also require patching all of the subsequent components which use libp11-kit.so separately. It would seem to me that the simpler solution would be to be able to change the paths inside one library, instead of adjusting it in multiple places. I've updated my merge request and added in a config option called env_override_paths, which should be disabled by default. Would this be acceptable? I fully understand that, by default, you may not want environmental overrides to enabled. We're certainly dealing with a minority edge-case here, where 99.9% of people using this package will not need the override support. So, let's make it an option and keep it off by default?
This would work fine for us. |
Add in the ability to dynamically adjust module and configuration paths at run-time via system environmental exports
Background: While trying to integrate PKCS11+HSM into a build system (Yocto Project), we wanted the build system to be able to use the HSM directly. However, The Yocto Project creates a sandboxed environment for each package which uses p11-kit during compilation. This means that the p11-kit modules and configurations cannot be found from within these sandboxed directories, as their paths are non-determinable at compile time. OpenSSL appears to use OPENSSL_CONF for this sort of dynamic configuration, so I've followed their lead and incorporated a similar p11_kit_getenv() method.