On 06/25/2010 04:37 PM, I wrote: > Maybe a better approach is a hybrid of our proposals: have ACLs instead > govern the right to _access_ and the right to modify, and then have a > polkit action that determines if someone has the right to activate a > connection that they can access. > > I think this could work. The way I see it, the right to "access" a > connection roughly means we trust them to use that connection, i.e. we > trust that they won't abuse the network that the connection describes > (or that we're willing to put up with it if they do). If someone is > allowed to access a connection but is not allowed to activate it, what > that probably means is that we're worried that the user will, say, annoy > other users by bringing that connection up and down incessantly [1]. > Thus, I'm assuming that if a user isn't allowed to activate a connection > that they can access, then they probably aren't allowed to activate any > connections. Thus, a polkit action would be good enough.
Marc Herbert sent me a few questions off-list about the terminology I used here, and now that I think about it, I've realized that I confused myself here. I'll try to clear up the confusion I've probably caused. We aren't (yet) going to be able to control who can "utilize" a connection. (I had been thinking "access" == "utilize" in my last mail.) Once a connection is activated, anyone on the system will be able to use it. The only thing we can control is who can modify, who can activate, and under what conditions is it eligible for autoactivation. What I really should have been talking about is "visibility". When we create a connection, we'd like have some control over who is allowed to see and use the data stored in that connection's settings. And if none of the logged-in users have been given the right to view a connection, then that connection is effectively "invisible" to the system and thus not eligible for autoactivation. I believe this is what Dan originally meant when he spoke of who can "access" a connection. I think my proposal still works with this modification, though. If someone can make a connection eligible for autoactivation by logging in but we still don't let them manually activate the connection, then that's probably because we don't trust them with manual activation, period. So polkit still works. Alright, maybe I better hurry up and start implementing this before I get confused again. :) We still need to work out how to deal with secrets storage, but at this point it looks like that issue can be addressed separately. Have a great one, Daniel _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list