Re: setEnvironmentVariable DBus method for wpasupplicant

Stef <stef memberwebs com> writes:

> My messages to networkmanager-list aren't getting through yet, but...
> Jouni Malinen wrote:
>> On Thu, Jul 24, 2008 at 02:29:32AM +0900, David Smith wrote:
>>> For implementing PKCS#11 support in the network manager gnome applet
>>> using gnome keyring as the backing store, it's necessary to tell
>>> wpasupplicant the environment variable of GNOME_KEYRING_SOCKET before
>>> loading the gnome keyring PKCS#11 library. This socket will be protected
>>> to the local user, but since wpasupplicant must run as root, it should
>>> be able to access it and indeed it must.
>> wpa_supplicant can actually be run without root capabilities when using
>> privacy separation. However, that may not be of much help here. Using
>> environment variable for this type of configuration for a library sounds
>> a bit odd, but maybe there is no better way of passing that information.
> It's not configuration per-se. The socket is per session, and could be
> different for multiple programs run on the same session. It would be
> nice if the gnome-keyring pkcs11 module could could use the DBus session
> bus to locate the daemon/socket. However PKCS#11 modules have to run in
> all sorts of strange applications, and DBus wasn't an option. :(
>> I have to say that I don't really like this at all.. If I understood the
>> design correctly, it may indeed be necessary to be able to set
>> GNOME_KEYRING_SOCKET. However, I don't see need for setting any other
>> environment variable. I would certainly prefer to do this in some other
>> way, but if this is the only feasible one, I would be fine with a
>> compromise that adds a new DBus command for setting GNOME_KEYRING_SOCKET
>> (i.e., just this particular environment variable, not arbitrary
>> variables). I would rather not go through the details of what external
>> programs could do by setting some other variables and as such, it would
>> be simpler to just limit this to a single variable as a workaround for
>> the particular issue.
> It's easy enough to get around. gnome-keyring already has something to
> address this problem. You can call the /org/gnome/keyring/daemon
> interface and use the GetSocketPath call, which will return the socket
> path of the currently running daemon. You can then easily set the
> correct environment variable in your process.

I've sent patches to opensc to allow for specifying init args to
C_Initialize in libp11 and the openssl pkcs11 engine. We can then make
use of that in wpasupplicant and provide a configuration parameter for
pkcs11 init args and add that as an optional argument to the existing
setSmartcardModules dbus interface. So nm-applet could check if it was
using gnome-keyring, get the socket path from dbus and send it to
wpasupplicant for pkcs11 init. Does that seem like a good solution to
everyone, as long as OpenSC accepts the init args patches? Setting aside
the fact that it still doesn't work on gnome-keyring's side because
wpasupplicant would not be running as the same user as the keyring
daemon... And I don't like that nm-applet has to have special code for
keyring's pkcs11 implementation, but I think that's unavoidable.

- dds

Attachment: pgpp3s65sjyKS.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]