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 _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
