Re: Removing user settings services

[Daniel Gnoutcheff <daniel gnoutcheff name>]

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