Re: Removing user settings services

[Dan Williams <dcbw redhat com>]

On Tue, 2010-06-22 at 16:39 -0400, Daniel Gnoutcheff wrote:
> Thanks for the comments!
> 
> On 06/22/2010 04:28 AM, Ludwig Nussel wrote:
> > I'm not sure the privileges need to be that fine grained as in your
> > proposal though. Physical access to a system likely allows to
> > terminate any connection anyways e.g. by unplugging the device or
> > it's wire or by hitting the kill switch. So the different
> > 'deactivate' types are kind of moot. I'd probably even declare that
> > the 'activate' privilege covers the deactivate cases so the
> > 'deactivate' privilege could be left out. A front-end could
> > nevertheless warn the user if she tries to deactivate a connection
> > of another, still logged in user of course.
> 
> Ah, excellent point! Yeah, remote users probably aren't going to want to
> mess with network settings, so the only meaningful cases for connection
> activation/deactivation are for local users, and well, yeah. WiFi
> killswitch. 'Nuff said.
> 
> Thanks for setting me straight on that! This makes things much simpler.
> I've updated the wiki page accordingly.
> 
> 
> >> Do we want to have connections that are automatically deactivated when a user
> >> logs out and/or locks their session? 
> > 
> > Terminating a connection on log out makes sense if it's charged per
> > time at least, like plain old modem connections. That avoids having
> > to accidentally pay for the connection while noone actually uses the
> > computer.
> 
> Right, and it probably applies even more clearly to private VPN
> connections, where the user really doesn't want to accidentally let
> other users use the connection.
> 
> We handle this pretty well right now because when the user logs out,
> that user's settings service goes away, and the connection disappears
> with it. If we get rid of user settings, we'll need to do this some
> other way.

I think the way this gets handled is that if there are no users which
have permission to activate/deactivate the connection are logged in, the
connection gets terminated.

Even though we kill user connections, we still have the concept of
system/user split through ACLs since we want to enforce visibility of
certain connections.  It's just that NM would be handling the user
connections and enforcing visibility instead of a service running in the
user session.

Here's how I think that works.  Remember that we have both ACL (which
controls who can actually see the connection) and PolicyKit (which
controls what you can do with the connection).

1) ACL only contains USER1 (analogous to a user connection today); and
thus is not seen by any other user on the system.  When USER1 logs out
this connection is terminated.

2) ACL is empty (analogous to a system connection today); thus allowing
all users to see it and control it.  When USER1 logs out this connection
isn't terminated since it's available to all users.  BUT each user still
is restrained by (optional) PolicyKit authentication, so just because
the ACL allows everyone doesn't mean that everyone can edit it or even
activate/deactivate it.  We still have robust PK permissions that can
disallow certain users to control networking at all.

Thoughts?

Dan