Re: setEnvironmentVariable DBus method for wpasupplicant
- From: Dan Williams <dcbw redhat com>
- To: stef memberwebs com
- Cc: hostap lists shmoo com, networkmanager-list gnome org
- Subject: Re: setEnvironmentVariable DBus method for wpasupplicant
- Date: Sun, 27 Jul 2008 12:31:31 -0400
On Fri, 2008-07-25 at 23:45 +0000, Stef wrote:
> Dan Williams wrote:
> > I think the real fix for this is to get Gnome Keyring using D-Bus, not
> > sockets. That needs to be done anyway. This sort of call in the
> > supplicant seems really ugly to me.
> Gnome Keyring supports a variety of standards and access methods for
> various things. It sits as a bridge between a bunch of technologies,
> some ancient and some modern.
> In this case wpasupplicant accessing gnome-keyring PKCS#11 via which
> is a standardized API for public key access and crypto operations. This
> API is provided by a module.
> Internally a socket it used to connect from the module to the
> gnome-keyring daemon. Why isn't Dbus used for this connection? We tried
> hard to make that work, but in the end:
In the end you need a well-known name for how to connect to the keyring.
The advantage with D-Bus is that you do have a well-known name to
connect to. The disadvantage of the current system is that every app
that wants to use Gnome Keyring needs to know the random gnome keyring
socket path via environment variables, which is a total fail for exactly
the reason presented in this case.
> * DBus has a rigid locking and threading model is incompatible with
> the threading model of PKCS#11 modules.
> * DBus provides no credentials information on who the other side of the
> caller is.
What kind of credentials are needed here? You'll get at least the uid
of the caller via SO_PEERCRED. Any other credentials need would be
passed inside the D-Bus message just like they are probably passed
around inside PKCS11 somewhere.
> This just isn't what DBus is designed for. This was discussed on the
> DBus mailing list.
> On the other hand, certain parts of gnome-keyring are exposed via DBus.
> And you can get the appropriate socket path for the current user
> session, via DBus.
Good! That should solve this issue then. The only reason to pass
random environment variables through the supplicant was to set the
keyring path IIRC. It should be pretty easy to get that path inside the
supplicant's PCKS11 code without having to resort to having the user
agent push down the environment variable array. We may need to invent
another command to tell the supplicant about the user we're requesting
credentials for of course.
] [Thread Prev