[PATCH] Support addiitional 'progname' tags
dwmw2 at infradead.org
Fri Dec 12 08:47:21 PST 2014
On Fri, 2014-12-12 at 17:27 +0100, Stef Walter wrote:
> 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.
> > 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.
It was actually "we are being loaded from NSS" that was the primary
motivation here. We wanted to avoid loading the trust slots in the NSS
case because we'll explicitly load libnssckbi.so (-> p11-kit-trust.so)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5745 bytes
Desc: not available
More information about the p11-glue