Re: Removing user settings services

[Daniel Gnoutcheff <daniel gnoutcheff name>]

On 06/24/2010 03:55 PM, Dan Williams wrote:
> On Thu, 2010-06-24 at 14:47 -0400, Daniel Gnoutcheff wrote:
>> On 06/23/2010 08:15 PM, Dan Williams wrote:
>> -) What do we do when no users are logged in at all?
<snip>
> I think here if the ACL is empty (meaning 'available to all') and
> 'autoconnect=true' it's a candidate for activation.

Yep, this is pretty much what I was thinking too.


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

Yeah, after thinking about it, I agree, as I've now thought of a use
case where we'd like this ("Ellen and the corporate laptops", just added
to the wiki).


Now, if we do take the approach of having ACLs govern activate and
modify permissions, the auto(dis)connect thing would become a problem
again, since we'd no longer have a list of who can only "access" a
connection. (As I originally imagined it, the non-secret parts of
connections would be visible to everyone.)

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.

(Counterexamples are welcome, of course. :) )

A polkit action to control modification is probably a good idea too; it
would be good to be able to say "don't let this wacko modify anything,
regardless of what the ACLs say".


As far as trying to simplify this, here's one thing we might take
advantage of: if someone has the right to modify a connection, they
almost certainly have the right to access it as well. So we could have a
single ACL, a list of users (and groups) allowed to access the
connection, and each entry could have a flag that indicates if the
corresponding user (or group) also has the right to modify it.

Of course, this would require having a special "everyone" entry, so that
we could cover cases like the one where everyone can access but only a
few can modify.


One last thought about ACLs: we may wish to put some additional controls
on who can edit them. For example, we may wish to let people create
connections that only they can see and use, but we might not want to let
such users create connections that others could use. (One such use case
is now on the wiki: the "Ellen and the office desktops" case, where we
don't want office users to share VPN connections.)

One way to handle this might be a "modify-acl" polkit action. Only those
who have this permission may edit the ACL of a connection or provide an
ACL when adding connections. And when someone creates a connection
without providing an initial ACL, we default to an ACL that makes the
connection private to the requesting user. Thus, users that can add
connections but can't modify ACLs may only add private connections.


Thoughts?


<snip>
>> 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.
<snip>
> I need to talk to a few more people about this to be more comfortable
> with the idea.

Sounds like a plan. Personally, I'm comfortable with both ACLs and this
approach, esp. if we allow groups to be listed on ACLs (which I think is
a very good idea.)


Have a great one,
Daniel


[1] You know, like an annoying grade-school student who rapidly flips a
light switch up-down-up-down on-off-on-off-on-off ... Man, I'm glad to
be outta there. :)