Re: disabling keyring

[Éric Brunet <Eric Brunet lps ens fr>]

On Wed, Oct 26, 2005 at 12:20:18PM -0400, Dan Williams wrote:
> > 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.

I don't actually how WPA or 802.1x work; all I am using is WEP. If one
user wants a network private to him, maybe it is more logical to store
information in its home directory rather than system wide (even if it is
as easy to store it system wise, with a flag specifying that such a key
is only for such user. Why not.) But the common case is that every user
on a given computer want to share their network keys with every user,
because, usually, all the users of a given laptop know and trust each
other. Shouldn't the efforts be geared to solving the most common case
first ?

By the way, as it is now, does it really work ? If user A logs in, enters
three passwords in a row to connect to his very private personnel secret
access point, and then logs out, does NM stops the connection and forget
all the keys ? I had the impression that killing nm_applet does not stop
the network connection; so if user B logs in after user A, he gets to use
the private network connection, 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.

That is great.

> However, anyone can write an info daemon, and said info daemon can pull
> info from files, from KConfig, from whatever.  That won't change.

Actually, I have started a bit looking into that. I have a patch,
completely untested (it compiles) which isolates all the calls to gconf
in 10 abstract functions. This is only for applet-dbus-info.c right now.
The idea is that the code is much nicer and easier to read, and it will
greatly facilitate the work of the courageous programmer porting
nm-applet to kde. For instance, the bulk of
nmi_dbus_get_network_properties becomes

 storage_get_string (applet->gconf_client, WIRELESS_NETWORKS,
				network, "essid", &essid);
 storage_get_int (applet->gconf_client, WIRELESS_NETWORKS,
				network, "timestamp", &timestamp);
 storage_get_int (applet->gconf_client, WIRELESS_NETWORKS,
				network, "key_type", &key_type);
 storage_get_int (applet->gconf_client, WIRELESS_NETWORKS,
				network, "auth_method", &auth_method);
 storage_get_bool (applet->gconf_client, WIRELESS_NETWORKS,
				network, "trusted", &trusted);

The patch is on http://tudia.nerim.net/nm/nm-cleanup.patch
It might make sense to apply and expand this patch.

Éric