> Correct, we need module-path explicit support to load any additional > modules not already loaded. > > But still we would require some kind of registration of these modules > via p11-kit, or pkcs11 URLs will not be usable from from privileged > processes if they are acquired from an unprivileged one.
Hm, I think you're conflating the "what module does wpa_supplicant itself load?" question (A: p11-kit-remote.so), with the "what modules are visible to/through the stub running in the user session?" question (A: the standard configured set). > We could, but the error surface is quite large. I don't believe we can > sufficiently expect to add such a code path in three+ libraries and > expect it to work the same way everywhere. The solution with getenv() > requires support only in the newly introduced module thus I find it > much cleaner. So you want p11-kit-remote to be in the default set for root (for certain apps?) and normally it'll fail to initialise unless the variable is set? Talk me through the security implications of that. I concede it only scares me; I have no specific attack model in mind. Let's assume we *don't* allow trusted certs through the remote, or you fail to convince me before you even start... :) -- dwmw2 _______________________________________________ p11-glue mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/p11-glue
