On 11.12.2014 16:52, David Woodhouse wrote: > There are cases where we want to use enable-in/disable-in options for a > whole *class* of programs. Such as 'python' or 'p11-kit-proxy.so'. > > This adds an internal API for managing extra prognames, and fixes the > enable-in/disable-in processing to handle them.
Thanks a lot much for doing the research and getting this patch together. > The proxy module now sets an additional progname of 'p11-kit-proxy.so', > and this can be used to control visibility of modules via the proxy > regardless of the actual program name in argv[0]. > > I'd also like p11-kit-proxy.so to take addtional 'extra prognames' via > the init_args.pReserved pointer in C_Initialize(). But unfortunately we > already processed the configuration in C_GetFunctionList() and decided > which modules to load, so it's too late by then. We'll need some > refactoring to make that possible. Unfortunately (even though I may have suggested it) I think this approach is a bit broken. In particular if p11-kit-proxy.so is loaded in a process, then *all* callers in that process (including for example gnutls) will get the enable-in/disable-in applied as if they were using p11-kit-proxy.so Can we pass an extra "p11-kit-proxy" progname into p11_modules_load_inlock_reentrant() directly? That would solve this one use case, and I think it's reasonable to only solve this rather than the broader scope. Stef
signature.asc
Description: OpenPGP digital signature
_______________________________________________ p11-glue mailing list p11-glue@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/p11-glue
