Re: [RFC] Fast-user-switching plans

[Simon Geard]

On Wed, 2010-06-09 at 16:28 -0700, Dan Williams wrote:
> I think it's clear that even if there are no user connections as such,
> that we still need secrets on a per-user basis for some connections.
> And that's not actually that hard to do, and we've got most of the code
> written for that already.

One more thought on that subject - not sure if it's a realistic concern
or not.

User secrets stored in gnome-keyring and equivalents are stored
securely, in such a way that no other user (even root) can readily [1]
obtain them. Can the same be done for user secrets stored at a system
level, i.e preventing a privileged user on one system from stealing
another user's credentials for a second system?

My viewpoint on this is our workstations at work, where practically
every developer has root access in order to do their job - that doesn't
mean they should be able to bring up a VPN link to my system at home.

[1] Yeah, I know that with enough work, a privileged user can get around
that, patching NM binaries, etc. But that's no reason to make it easy...

Simon.


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Dan Williams]

On Sun, 2010-06-06 at 00:30 +1200, Simon Geard wrote:
> On Fri, 2010-06-04 at 19:24 -0700, Dan Williams wrote:
> > On Wed, 2010-06-02 at 23:44 +1200, Simon Geard wrote:
> > > On Wed, 2010-06-02 at 00:45 -0700, Dan Williams wrote:
> > > > The one benefit of user connections is that they follow you if you back
> > > > up your homedir and switch machines :)  I don't think that's enough of a
> > > > benefit to keep them around though.
> > > 
> > > Also if you periodically update your OS - e.g installing a new Ubuntu
> > > release every six months. Stuff in $HOME stays - stuff in /etc doesn't.
> > 
> > Yup.  Though we could mitigate that by providing usable backup/restore
> > capability that dumps a bunch of keyfiles describing your connections
> > into a tarball or something.
> 
> Is a user going to appreciate that, though? I.e, will they realise that
> their network settings are something that needs manually backing up? Or
> will they learn this out after installing an update, and finding they've
> lost the VPN settings they assumed were stored safely in $HOME?

I think it's unclear... some users would based on previous expectations.
If we make import/export work well we mitigate that.  But there are also
users for which this just doesn't matter because they don't go through
the trouble of rsyncing $HOME every time they switch machines.  It's
clear this is a downside of the decision though.

The question is, is it enough of a downside that it outweighs the
benefits?  That's a nuanced question but I think at this point my
impression is that the benefits are greater.  Namely, simpler
architecture is more flexible and allows easier creation of different UI
for different situations, which clearly benefits all users (this is the
"big one").  Second, this simplification reduces the number of
code-paths making future maintenance easier.  Third, it enables
fast-user-switching and multi-seat configurations which is something
that people have also been asking about for a long time.  Fourth, it
also enables better integrated network configuration editing and
creation from just about anywhere on the system.

Either way, it's important to understand all the tradeoffs in this sort
of decision.

> Actually, here's a thought - the login/password details for each
> connection are currently stored in the user's keyring. If you were to
> turn "user connections" into "system connections with ACL", how would
> that piece work? If system connections are removed or their permissions
> changed, are keys removed from the keyring?

That part depends on the connection; if secrets were pushed with the
connection when it was created, user secrets wouldn't be required.
However, there are cases where they would be desirable even if the
secrets were already stored for it.  In that case, we need to ensure we
get signaling right, but we need to do that anyway.

If the connection ACL is changed in such a way that certain users are no
longer able to use that connection, then one of two things happens... if
the user agent that has secrets already stored for that connection is
running, then it would remove the stored secrets.  If it is not running,
the secrets would stay in the keyring and could optionally be removed by
the user agent when the agent starts up the next time.

I think it's clear that even if there are no user connections as such,
that we still need secrets on a per-user basis for some connections.
And that's not actually that hard to do, and we've got most of the code
written for that already.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Simon Geard]

On Fri, 2010-06-04 at 19:24 -0700, Dan Williams wrote:
> On Wed, 2010-06-02 at 23:44 +1200, Simon Geard wrote:
> > On Wed, 2010-06-02 at 00:45 -0700, Dan Williams wrote:
> > > The one benefit of user connections is that they follow you if you back
> > > up your homedir and switch machines :)  I don't think that's enough of a
> > > benefit to keep them around though.
> > 
> > Also if you periodically update your OS - e.g installing a new Ubuntu
> > release every six months. Stuff in $HOME stays - stuff in /etc doesn't.
> 
> Yup.  Though we could mitigate that by providing usable backup/restore
> capability that dumps a bunch of keyfiles describing your connections
> into a tarball or something.

Is a user going to appreciate that, though? I.e, will they realise that
their network settings are something that needs manually backing up? Or
will they learn this out after installing an update, and finding they've
lost the VPN settings they assumed were stored safely in $HOME?

Actually, here's a thought - the login/password details for each
connection are currently stored in the user's keyring. If you were to
turn "user connections" into "system connections with ACL", how would
that piece work? If system connections are removed or their permissions
changed, are keys removed from the keyring?

Simon.


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Dan Williams]

On Wed, 2010-06-02 at 23:44 +1200, Simon Geard wrote:
> On Wed, 2010-06-02 at 00:45 -0700, Dan Williams wrote:
> > The one benefit of user connections is that they follow you if you back
> > up your homedir and switch machines :)  I don't think that's enough of a
> > benefit to keep them around though.
> 
> Also if you periodically update your OS - e.g installing a new Ubuntu
> release every six months. Stuff in $HOME stays - stuff in /etc doesn't.

Yup.  Though we could mitigate that by providing usable backup/restore
capability that dumps a bunch of keyfiles describing your connections
into a tarball or something.

Dan


___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Simon Geard]

On Wed, 2010-06-02 at 00:45 -0700, Dan Williams wrote:
> The one benefit of user connections is that they follow you if you back
> up your homedir and switch machines :)  I don't think that's enough of a
> benefit to keep them around though.

Also if you periodically update your OS - e.g installing a new Ubuntu
release every six months. Stuff in $HOME stays - stuff in /etc doesn't.

Simon.


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Dan Williams]

On Fri, 2010-05-21 at 08:53 +0200, Ludwig Nussel wrote:
> Daniel Gnoutcheff wrote:
> > I've been spending some time thinking about how to get N-M to work with
> > fast-user-switching. Here are some possible solutions that I have heard of 
> > or
> > thought of, presented for review.
> > [...]
> > Well, once again, thanks for reading all that! Comments, corrections, better
> > ideas?
> 
> 5. (or rather 2b?) Get rid of the user settings concept
> 
> I always found that concept weird and the wrong way around. Those
> network connections are not private to some user anyways. So always
> have all network connection settings system global (ie in /etc). You
> don't need to store an owner of a connection at all, owner is always
> root. Use polkit to determine whether a user trying to edit,
> start/stop network connections etc is allowed to do so. Credentials
> such as passwords or client certificates could still be requested
> from the frontend (ie the user that tries to start a connection) if
> storing them in plain text globally isn't desired.

Yeah, I've been thinking more about that recently too.  The  main cases
are more "personal" connections like VPNs where often you don't want to
grant VPN access to anyone you happen to let use your computer.  There
certainly has to be some gating of who can start, stop, and modify
connection information, and that's probably got to based on users.
Essentially, ACLs on a per-connection basis.

PolicyKit has some neat stuff here, but there's also always the fallback
of having a list of users stored along with the connection data itself
that can start/stop the connection, and another list that can modify
that connection.

And further posts are correct; network namespaces may well provide the
ability in the future to tie a specific user's traffic to a specific
outgoing interface and prevent others from using that connection.
Network interfaces and routing are not necessarily machine-wide when
network namespaces enter the picture, and we should have a story around
that.

But going forward, I think we do need to evaluate whether user
connections should really stick around given that we can get the same
security benefits by ACL-ing system connections.

The one benefit of user connections is that they follow you if you back
up your homedir and switch machines :)  I don't think that's enough of a
benefit to keep them around though.

Dan


___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Graham Lyon]

On 28 May 2010 21:41, Martijn Lievaart  wrote:
>
> Very cool! Sounds like there is still much more integration needed -- the
> whole user environment should use such a namespace, and the global
> networkmanager can interact with the user namespaces --, but definately a
> great step in the right direction. I any work done into moving a user
> environment into such a namespace?
>
> M4
>
>
None that I know of. As far as I'm aware this is a very fresh project and is
only used by the linux containers project to create entirely segregated
containers to run as virtual machines. If we were to head down this route,
how would it be achieved? Perhaps there could be a network namespace per
user where all the user's own connections are and then a global one for
global connections (naturally a bridge interface between the two for one the
user just wants to use the globally available connection). This would solve
the highly contrived use case of already having an internet connection and
wanting to connect via 3g in a different session; however it would not solve
the problem of wanting to connect to a different wireless access point if
the wireless card is already in use by another session. Perhaps more thought
is needed on that...?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Martijn Lievaart]

On 05/28/2010 07:13 PM, Graham Lyon wrote:
Now I'm no expert on this particular area but I recall that there are 
now several ways to break a system up into "containers" [1] which is 
often used to do things like virtualisation. However, would it be 
possible to utilize the network "namespace" component [2] in order to 
break off a user's mobile broadband connection into a namespace that 
only their processes have access to? I'm just bringing this up because 
maybe the technology to do what everyone seems to agree "should" be 
possible already is in the kernel.


Like I said, I'm no expert but I think I'll read into it out of 
curiosity... just wanted to throw it out there for anyone else who 
might be curious about looking down this path...


-Graham

[1] http://lxc.sourceforge.net 
[2] http://lxc.sourceforge.net/network.php



Very cool! Sounds like there is still much more integration needed -- 
the whole user environment should use such a namespace, and the global 
networkmanager can interact with the user namespaces --, but definately 
a great step in the right direction. I any work done into moving a user 
environment into such a namespace?


M4

___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Graham Lyon]

Now I'm no expert on this particular area but I recall that there are now
several ways to break a system up into "containers" [1] which is often used
to do things like virtualisation. However, would it be possible
to utilize the network "namespace" component [2] in order to break off a
user's mobile broadband connection into a namespace that only their
processes have access to? I'm just bringing this up because maybe the
technology to do what everyone seems to agree "should" be possible already
is in the kernel.

Like I said, I'm no expert but I think I'll read into it out of curiosity...
just wanted to throw it out there for anyone else who might be curious about
looking down this path...

-Graham

[1] http://lxc.sourceforge.net
[2] http://lxc.sourceforge.net/network.php

On 28 May 2010 17:23, Martijn Lievaart  wrote:

> On 05/28/2010 03:46 PM, Marc Herbert wrote:
>
>> Le 28/05/2010 09:16, Simon Geard a écrit :
>>
>>
>>
>>> Simply because IP is not designed like this at all. NetworkManager's
 scope is make IP networking easy; not to re-invent the Internet.


>>> Actually, couldn't something be done with Netfilter rules? The
>>> connection (a VPN, say) might technically be system-wide, but with rules
>>> enforcing that only applications running as a certain user could send
>>> and receive packets on it? Perhaps imperfect, but a starting point...
>>>
>>>
>> Sockets have owners, but I doubt very much you can extend that to
>> packets. The "end-to-end principle" strikes again. So this rules out
>> Netfilter I am afraid.
>>
>>
>>
>
> Netfilter has an owner match, which does extend the owner to packets, more
> or less. However, you would als have to consider routing. This also looks
> possible with tc rules matching on the same netfilter match. However I
> suspect this will never work satisfactorily, IP was just never designed to
> do things like this.
>
> I do think that we will move in this general direction, but with a more
> light-VM-per-user like aproach, where every user has it's own view of the
> filesystem, it's own networking "view" etc. In other words, I suspect this
> is much bigger than can be handled now.
>
> HTH,
> M4
>
>
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Martijn Lievaart]

On 05/28/2010 03:46 PM, Marc Herbert wrote:

Le 28/05/2010 09:16, Simon Geard a écrit :

   

Simply because IP is not designed like this at all. NetworkManager's
scope is make IP networking easy; not to re-invent the Internet.
   

Actually, couldn't something be done with Netfilter rules? The
connection (a VPN, say) might technically be system-wide, but with rules
enforcing that only applications running as a certain user could send
and receive packets on it? Perhaps imperfect, but a starting point...
 

Sockets have owners, but I doubt very much you can extend that to
packets. The "end-to-end principle" strikes again. So this rules out
Netfilter I am afraid.

   


Netfilter has an owner match, which does extend the owner to packets, 
more or less. However, you would als have to consider routing. This also 
looks possible with tc rules matching on the same netfilter match. 
However I suspect this will never work satisfactorily, IP was just never 
designed to do things like this.


I do think that we will move in this general direction, but with a more 
light-VM-per-user like aproach, where every user has it's own view of 
the filesystem, it's own networking "view" etc. In other words, I 
suspect this is much bigger than can be handled now.


HTH,
M4

___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Marc Herbert]

Le 28/05/2010 09:16, Simon Geard a écrit :

>> Simply because IP is not designed like this at all. NetworkManager's
>> scope is make IP networking easy; not to re-invent the Internet.
> 
> Actually, couldn't something be done with Netfilter rules? The
> connection (a VPN, say) might technically be system-wide, but with rules
> enforcing that only applications running as a certain user could send
> and receive packets on it? Perhaps imperfect, but a starting point...

Sockets have owners, but I doubt very much you can extend that to
packets. The "end-to-end principle" strikes again. So this rules out
Netfilter I am afraid.

On the other hand, maybe SELinux or POSIX capabilities could do
something at the socket level.


___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Simon Geard]

On Thu, 2010-05-27 at 17:19 +0100, Marc Herbert wrote:
> Le 27/05/2010 15:26, José Queiroz a écrit :
> > 
> > And that's the point. If the system offers us the separation of
> > resources like files, why can't a network connection be personal?
> 
> Simply because IP is not designed like this at all. NetworkManager's
> scope is make IP networking easy; not to re-invent the Internet.

Actually, couldn't something be done with Netfilter rules? The
connection (a VPN, say) might technically be system-wide, but with rules
enforcing that only applications running as a certain user could send
and receive packets on it? Perhaps imperfect, but a starting point...

Simon.


signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Marc Herbert]

Le 27/05/2010 15:26, José Queiroz a écrit :
> 
> And that's the point. If the system offers us the separation of
> resources like files, why can't a network connection be personal?

Simply because IP is not designed like this at all. NetworkManager's
scope is make IP networking easy; not to re-invent the Internet.


> But, try to look from the user point of view: "The network connection
> that this computer offers me doesn't fits my needs. I have this other
> connection that's better to me, but I don't want that other users on
> the same machine use it, as it is charged by traffic".

So this connection is charged by traffic, yet you:
- leave amule running on it
- let other users use the connected computer.
This looks quite wrong to me.

As you said: "you need a new model". But not just a new NetworkManager
model I am afraid. You need a brand new networking model.


Cheers,

Marc


___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[José Queiroz]

2010/5/27 Ludwig Nussel :
>>
>> I don't agree. Historically, network connections was a system-wide
>> resource. But if you start thinking that a 3G connection is a personal
>> resource, as personal as a cellphone, you will see that we need a
>> better model that the one we use nowadays. This is because any user,
>> and any process, may use this resource, without any control.
>
> Sure, you have to trust the computer you plug your device into.
>

And that's the point. If the system offers us the separation of
resources like files, why can't a network connection be personal?

>> You can imagine that one user start a P2P download, with some kind of
>> client, said, amule, then leaves the machine's console. Then another
>> user comes to the console, and opens a new session, without logging
>> out the previous one. A classical case of "user switching".
>>
>> The he/she plugs in a 3g modem, and start a new connection. As the
>> network settings, now, are system wide, the connection stablished by
>> the user will be used by the amule process left by the previous user,
>> also.
>
> A computer system shared by multiple users at the same time where
> every user has to bring his own modem to get the system online? That
> sounds rather unrealistic to me.
>

This is because you're thinking only on the system side. "I do have a
network connection, why do this user needs another one?"

But, try to look from the user point of view: "The network connection
that this computer offers me doesn't fits my needs. I have this other
connection that's better to me, but I don't want that other users on
the same machine use it, as it is charged by traffic".
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Ludwig Nussel]

José Queiroz wrote:
> 2010/5/21 Ludwig Nussel :
> > Daniel Gnoutcheff wrote:
> >> I've been spending some time thinking about how to get N-M to work with
> >> fast-user-switching. Here are some possible solutions that I have heard of 
> >> or
> >> thought of, presented for review.
> >> [...]
> >> Well, once again, thanks for reading all that! Comments, corrections, 
> >> better
> >> ideas?
> >
> > 5. (or rather 2b?) Get rid of the user settings concept
> >
> > I always found that concept weird and the wrong way around. Those
> > network connections are not private to some user anyways. So always
> > have all network connection settings system global (ie in /etc). You
> > don't need to store an owner of a connection at all, owner is always
> > root. Use polkit to determine whether a user trying to edit,
> > start/stop network connections etc is allowed to do so. Credentials
> > such as passwords or client certificates could still be requested
> > from the frontend (ie the user that tries to start a connection) if
> > storing them in plain text globally isn't desired.
> 
> I don't agree. Historically, network connections was a system-wide
> resource. But if you start thinking that a 3G connection is a personal
> resource, as personal as a cellphone, you will see that we need a
> better model that the one we use nowadays. This is because any user,
> and any process, may use this resource, without any control.

Sure, you have to trust the computer you plug your device into.

> You can imagine that one user start a P2P download, with some kind of
> client, said, amule, then leaves the machine's console. Then another
> user comes to the console, and opens a new session, without logging
> out the previous one. A classical case of "user switching".
> 
> The he/she plugs in a 3g modem, and start a new connection. As the
> network settings, now, are system wide, the connection stablished by
> the user will be used by the amule process left by the previous user,
> also.

A computer system shared by multiple users at the same time where
every user has to bring his own modem to get the system online? That
sounds rather unrealistic to me.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[José Queiroz]

2010/5/21 Ludwig Nussel :
> Daniel Gnoutcheff wrote:
>> I've been spending some time thinking about how to get N-M to work with
>> fast-user-switching. Here are some possible solutions that I have heard of or
>> thought of, presented for review.
>> [...]
>> Well, once again, thanks for reading all that! Comments, corrections, better
>> ideas?
>
> 5. (or rather 2b?) Get rid of the user settings concept
>
> I always found that concept weird and the wrong way around. Those
> network connections are not private to some user anyways. So always
> have all network connection settings system global (ie in /etc). You
> don't need to store an owner of a connection at all, owner is always
> root. Use polkit to determine whether a user trying to edit,
> start/stop network connections etc is allowed to do so. Credentials
> such as passwords or client certificates could still be requested
> from the frontend (ie the user that tries to start a connection) if
> storing them in plain text globally isn't desired.
>
> cu
> Ludwig
>

I don't agree. Historically, network connections was a system-wide
resource. But if you start thinking that a 3G connection is a personal
resource, as personal as a cellphone, you will see that we need a
better model that the one we use nowadays. This is because any user,
and any process, may use this resource, without any control.

You can imagine that one user start a P2P download, with some kind of
client, said, amule, then leaves the machine's console. Then another
user comes to the console, and opens a new session, without logging
out the previous one. A classical case of "user switching".

The he/she plugs in a 3g modem, and start a new connection. As the
network settings, now, are system wide, the connection stablished by
the user will be used by the amule process left by the previous user,
also.

The more I think about it, the more I feel that we need a new model. :-/
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [RFC] Fast-user-switching plans

[Ludwig Nussel]

Daniel Gnoutcheff wrote:
> I've been spending some time thinking about how to get N-M to work with
> fast-user-switching. Here are some possible solutions that I have heard of or
> thought of, presented for review.
> [...]
> Well, once again, thanks for reading all that! Comments, corrections, better
> ideas?

5. (or rather 2b?) Get rid of the user settings concept

I always found that concept weird and the wrong way around. Those
network connections are not private to some user anyways. So always
have all network connection settings system global (ie in /etc). You
don't need to store an owner of a connection at all, owner is always
root. Use polkit to determine whether a user trying to edit,
start/stop network connections etc is allowed to do so. Credentials
such as passwords or client certificates could still be requested
from the frontend (ie the user that tries to start a connection) if
storing them in plain text globally isn't desired.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[RFC] Fast-user-switching plans

[Daniel Gnoutcheff]

I've been spending some time thinking about how to get N-M to work with
fast-user-switching. Here are some possible solutions that I have heard of or
thought of, presented for review.


--
1: Multiple user settings services

This is my favorite idea so far.

Instead of attempting to claim a well-known bus name, user settings services
would use their unique bus names and "register" themselves with the N-M daemon.
The daemon would use ConsoleKit to determine which session each settings service
comes from, and it will permit up to one settings service per session.
ConsoleKit would also be used to determine which session(s) are active, and N-M
will only pay attention to the settings service(s) that represent the active
session(s).

In its most basic form, this approach would require the addition of just one
method somewhere in N-M's DBus interface, something like

  org.freedesktop.NetworkManager.RegisterUserSettingsService (
in STRING bus_name,
in OBJECT_PATH settings_root )

where 'bus_name' is the bus name of the new user settings service, and
'settings_root' is an implementation of org.freedesktop.NetworkManagerSettings
that lives under that name.

I wouldn't plan to worry about multiseat quite yet; for now, N-M would only pay
attention to the first seat. A good place to start I think, especially since I
hear that ConsoleKit doesn't actually do multiseat just yet. However, if/when we
do support multiseat, this API probably wouldn't need much (if any) adjustment.

Oh, and for backwards compatibility, if something claimed
'org.freedesktop.NetworkManagerUserSettings', we would treat that as equivalent
to the call
  RegisterUserSettingsService (
"org.freedesktop.NetworkManagerUserSettings",
"/org/freedesktop/NetworkManagerSettings" )


---
2. Move user settings management down to the daemon

Under this plan, the daemon would take on responsibility for storing and acting
on user settings data. It would use ConsoleKit to determine what user is at the
console, and it would act on the settings data from that user. It would provide
some kind of DBus interface that would allow users to edit only their own
settings data.

This approach is interesting in that it would address the fast-user-switching
and user-settings-editing-over-DBus problems at the same time. It would also
simplify NM clients considerably, which would be nice since where are multiple
client implementations and only one daemon implementation. Indeed, we would not
necessarily need to have an always-running client, which I imagine would be
convenient for cnetworkmanager. Nonetheless, as I discussed in my message about
security, I don't think we want to do this (lots of stuff in UID 0, no more
gnome-keyring, etc.).

As for duplicated functionality among N-M clients, that probably can be
mitigated by making a shared library for them to use, so I'm not too worried
about that.


--
3. Make N-M a pure "mechanism"

This idea has been proposed before, but just for completeness: this would take
the idea of "settings services" out of the N-M core daemon, and the system
settings service and N-M clients would only send settings when asking N-M to
actually connect to a network. N-M would use PolicyKit to determine who is
allowed to control network settings, so e.g. only users at an active console can
connect to a new network.

The nice thing about this is that it makes the daemon as simple as possible. It
wouldn't have to worry much at all about manging settings and tracking who's at
the active console. We would just use PolicyKit the way it was designed to be
used. This also might make it easier to do things like support fine-grained
policies.

However, the user settings service concept is useful enough that I think it's
worth keeping. For one, it implicitly enforces the policy of "one NM client per
session". Without that, I'm not sure what we'd do if someone ended up running
multiple NM clients. More importantly, there are cases were we want to update
settings data while the connection is up (e.g. the seen-bssids list for wifi
networks), so to a certain extent we do want to have a settings store that
exists for the life of the connection.



4. Voluntary handoff

Have every NM client hold the 'org.freedesktop.NetworkManagerUserSettings' bus
name if and only if they are in the active session.

The big problem I have with this is that I just don't see how we can make it
robust. While DBus does have some nice mechanisms for bus name replacement, I
don't see a good way to prevent a buggy or malicious NM client from grabbing the
name and never letting go. The best I can think of would be to use SELinux or
something to ensure that only trusted NM clients could ever grab the
'NetworkManagerUserSettings' name, and then try to ensure that all of these
clients always use DBUS_NAME_FLAG_ALLOW_REPLACEMENT. But it still feels fragile