Re: Removing user settings services

[Daniel Gnoutcheff <daniel gnoutcheff name>]

On 06/23/2010 08:15 PM, Dan Williams wrote:
> 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.

I like this idea in general, though there are a few things we have to be
careful of:

-) What do we do when no users are logged in at all? There are quite a
few connections that should get activated anyway so that they are ready
to go when the next user logs in. Perhaps a way to handle this is to
leave a connection running if it can be activated by anyone.

-) We want to be careful about the case of a lab computer or a server.
There, we don't want *anyone* except the sysadmin to even be able to
activate connections. However, we still very much want the wired (or
possibly wifi) connection(s) to be activated at all times, _especially_
when the sysadmin is not logged in. Perhaps a way to handle this is to
think in terms of "visibility" rather than "right to activate", as in
"everyone can 'view' the wired connection, so we leave it on".


> 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.

Interesting! This is actually quite different from how I imagined it: I
was imagining that we'd have separate ACLs for the right to modify and
the right to activate, and polkit rules would control who could add
connections and who could override the ACLs (so admins could fix it if
we ended up with messed-up ACLs or something).

But I like this simpler idea, I think it would cover most (if not all)
of the use cases we care about.

The only case (I think) where having two ACLs would be helpful is if we
want to let a user activate and modify some connections but only
activate (not modify) others. I guess the questions to ask are:
1. Is there a real use case where we would want that?
2. If so, is it worth supporting?
I haven't thought of any use-cases yet, though the case of "Max and the
family computer" (on the wiki page) comes close.

The main concern I have is usability. If someone adds a user to the ACL
(via nm-connection-editor, say), that user still might have no access to
the connection if they are blocked by polkit rules. Could that cause
confusion and frustration?


Finally, I'd like give a plug for an idea I have (also listed on the
wiki): we may not need to implement ACLs ourselves at all. Instead, we
could have a given connection be visible to either (1) a single user,
(2) users in a specified unix group, or (3) any user in the system.

Thus, in those cases where we really need an ACL, we can let a unix
group be the ACL. A unix group is basically a list of users, just like
the ACLs we're thinking of are basically lists of users. But unix groups
have the advantage of many good, pre-existing tools for managing them.
So it would be more convenient for sysadmins, as they can use tools they
already know. And, as a bonus, this might a little simpler to implement
than custom-made ACLs, esp. when it comes to making a GUI editor for all
this.

The disadvantage is that only sysadmins can edit unix groups. However,
from a usability POV, this might actually be a good thing, since if we
use polkit rules, then it's already true that only sysadmins have full
control over who can do what with a given connection.


BTW I've edited the wiki page considerably since I first posted it here.
I'd encourage anyone interested to get a live.gnome.org account and
subscribe to that page. :)


Hope this helps!

Have a great one,
Daniel