Re: Do we have plan to do finer grained PolicyKit support for Networkmanager?

[Dan Williams <dcbw redhat com>]

On Tue, 2009-09-01 at 15:12 +0800, Bin Li wrote:
> Hi,
> 
>   NetworkManager currently only supports one PolicyKit privilege. That
> is whether a user is allowed to modify administrator defined
> connections or not. There is no way to disallow users to define their
> own network configurations. 

Right, we do want to do this.  I think it's more possible with NM 0.8
and PolicyKit 1.0 where the actual authentication is simpler.  Having
finer grained permissions was always the plan.

To disallow activation of user connections, we'd want to add a PolicyKit
permission for it, and then do the corresponding work in nm-manager.c's
impl_activate_connection() handler.  We'd also want to make the Policy
object ignore user connections when selecting which connections to
connect to automatically, and also set a "permissions" bit in the system
settings service to indicate that user connections weren't allows so the
UI can update accordingly.

>   There's only org.freedesktop.network-manager-settings.system.modify,
> introduce something like
> org.freedesktop.network-manager-settings.user.modify so NM can
> determine whether it should accept user settings.
> 
>   Also we could separate the action in more grained, such as 
> org.freedesktop.network-manager-settings.system.modify
> org.freedesktop.network-manager-settings.system.add
> org.freedesktop.network-manager-settings.system.delete 

I thought about that, but can't see a use-case.  If you can *add*
connections, then that's the same thing as modifying them.  It makes no
sense to deny modify, but allow add, since the user could just add the
connection they wanted instead of modifying an existing one.  Delete by
itself also doesn't make a lot of sense.  I view the three permissions
as a unit because in reality, I can't think of cases where you'd
actually need to split them up.

> and the same for .user .
> 
> 
> And you may even want to specifically allow or disallow adding for
> specific network types like wired, wireless, VPN, etc.

Definitely.  There are now permissions in the system settings service
that the UI can check for, and this sort of thing would be used to allow
the UI to intelligently enable/disable elements.

> You probably also want to have the ability to enable/disable wireless
> in general and enable/disable networking covered.

Yes.  I've already got permissions for allowing wifi connection sharing
defined, because that was already an issues we've run into.

> You can default all of these to the current settings, but adding these
> would allow more lock-down opportunities.

Maybe we should make the "permissions" field 64-bit instead of 32 :)  I
guess we probably could have more than 32 permissions.  That's fine as
we're still in flux.

If you'd like to take a look at these, I can point you in the right
direction.

Dan