Re: disabling keyring
- From: Dan Williams <dcbw redhat com>
- To: Éric Brunet <Eric Brunet lps ens fr>
- Cc: networkmanager-list gnome org
- Subject: Re: disabling keyring
- Date: Wed, 26 Oct 2005 12:20:18 -0400
On Wed, 2005-10-26 at 18:07 +0200, �ic Brunet wrote:
> > Eventually, once we have some sort of system-wide configuration
> > framework, we'll pull data from there and support this sort of thing,
> > including (most likely) global wireless keys and such. But no such
> > thing exists.
> if this framework existed, would it replace or supplement
> the framework of storing in home directories ? (I would say replace, as I
> wouldn't see the point of storing any data in home directories. Putting
> everything in one place would be more robust and simpler, no ?)
Not necessarily, some of this stuff is technically per-user. Think
about WPA and 802.1x... You can use certificates to authenticate
yourself, login usernames/passwords for VPN and RADIUS and EAP, etc.
These things are explicitly per-user, they are _not_ system wide
configuration options. Therefore, they should get stored in the user's
local storage, which happens to be in their home directory.
Now, if we have a system-wide configuration framework, whatever that may
be, the user can obviously choose to store their personal authentication
certificate in the system-wide store rather than their user store. As
such it would be available to NetworkManager at boot time as well. But
again, I stress that not everything is system-wide.
Another scenario for you: if you store your 802.1x auth certificate on
a keyring token, somewhat like Sun's SunRay systems. If you have to
auth to the network with that certificate, it's not available to the
system until you insert your token. That is 100%, unequivocally
per-user, and should not (and cannot) be set system wide. Think about
these sorts of things.
> > In the GNOME world, that could be GConf (since you don't
> > need to be logged in to use GConf default & mandatory settings), or it
>
> I should say that it shouldn't be gconf, as NetworkManager itself should
> be desktop neutral: it makes sense that gnome-applet uses gconf, but
> not NetworkManager, no ?
NetworkManager is not, I repeat not, desktop-specific. It is built to
be desktop-agnostic. Which is another reason why we do the
configuration the way we do.
There is another daemon, named the "info" daemon, that passes stuff like
wireless networks and other things to NetworkManager, which runs in the
user's session. NetworkManager will not connect to a wireless network
until that daemon is running. Currently, that daemon is also the Gnome
NM applet.
However, anyone can write an info daemon, and said info daemon can pull
info from files, from KConfig, from whatever. That won't change.
So what happens when the user logs out? Well, you would have a copy of
the info-daemon running all the time, and using the magic of dbus, the
"nobody"/system-wide info-daemon relinquishes it's dbus service (which
is org.freedesktop.NetworkManagerInfo) to the user-session info-daemon.
When the user-session info-daemon exits, the "nobody" info-daemon then
grabs the service again, and all is well. It doesn't matter where the
information comes from, as long as it comes from somewhere.
What we need is a system-wide config framework for the "nobody"
info-daemon to read from, and on Gnome systems, GConf would work since
it already has system-defaults and mandatory settings in its API. It
could also be text-files in /etc/sysconfig, but then we have to write
reams of parsing code to deal with that, and I don't like this option
anyway.
Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]