On Fri, Sep 4, 2009 at 1:29 AM, Dan Williams <[email protected]> wrote:
> 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. > Yes, I would like to take a look at these, I just know about the code now, any idea? Thanks! > > Dan > > >
_______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
