Re: Removing user settings services

[Dan Williams <dcbw redhat com>]

On Thu, 2010-06-24 at 14:47 -0400, Daniel Gnoutcheff wrote:
> 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.

I think here if the ACL is empty (meaning 'available to all') and
'autoconnect=true' it's a candidate for activation.

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

I think this case is empty ACL (ie, 'available to all') but only the
admin user has the PolicyKit privileges to control networking.  Thus,
lab users are blocked from doing anything with the network, and the
connection will stay up no matter who's logged in.

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

Yeah, I started there yesterday and thought "this gets complicated" and
tried to think of a way to simplify it.  And since POlicyKit handles the
authorization, we don't  need to do *too* much with the ACLs.  It might
be inappropriate to even call them ACLs really, not sure.

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

Yeah, everything else I came up with was more complicated and seemed
pretty confusing to normal users.

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

True.  Since the PolicyKit auth is global to all requests for that
permission, this wouldn't be possible in the system I've proposed.  So
you might be right, this does sound like a worthwhile thing to have
(modify some but no others).

> 1. Is there a real use case where we would want that?

Yes, I think so.

> 2. If so, is it worth supporting?

Yes, I think so, as long as it doesn't horribly complicate things.  And
I don't think it will.  The largest complication is going to be
explaining this to admins and users, and that's something we need to do
anyway.

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

It might, but I think as long as we set things up to work smoothly by
default, and document what goes on, it's not a huge problem. There are a
ton of ways to shoot yourself in the foot when you run off into the
woods with a loaded rifle, and we can't watch out for all of them.  We
can give users good guidance, make sure that it's not *necessary* to
change things unless there's a good reason (ie, works-by-default), and
provide documentation if people do want to change things.

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

Right, this has merit, but Unix groups aren't always appropriate.  They
are usually a pretty big hammer for the nail people are using.  That
does *not* mean they aren't useful.  But often using groups requires
more administration itself, which isn't always clear how to set up (does
it come from LDAP?  /etc/groups?  NIS?).  If it's not hard, I think we
should support restriction by both group and user.

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

Right, would be worth checking this out more to see what potential
problems are.  For example, the administration tools that exist now for
distros aren't particularly great, especially in the user/group admin
area in many cases.  As above, the group information could come from a
variety of different places, and admin tools typically cover only one or
two of those.  That's a failing of admin tools on Linux in general
though, and not one we can/should try to fix since it's such a huge
problem space.

I need to talk to a few more people about this to be more comfortable
with the idea.

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

Yup, this is a big one.  Groups are pretty coarse-grained and don't
scale very well to larger organizations, which is something that
PolicyKit helps fix.

One option is to make groups less central, but available for use if
desired.

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

Looked over it yesterday, going to keep doing so.  Discussions like this
are (I think) better on a list, with the Wiki page providing summary,
plans, and use-cases, like you've done so far.

Thanks again!

Dan