[Fwd: augeas, dbus and policykit]

[David Zeuthen]

Hi,

On Tue, 2008-05-06 at 18:17 +0200, Harald Hoyer wrote:
> Moving this to the correct list :)
> 
> -------- Original Message --------
> Subject: augeas, dbus and policykit
> 
> Because augeas ( http://augeas.net ) enables us to read/modify/write config files easily, I envision a dbus
> service which provides the augeas interface filtered by config files and checks access with policykit.
> 
> That means, if you want to modify e.g. /etc/grub.conf, you first acquire the action_id
> "com.redhat.conf.grub.write" and then talk to the "com.redhat.conf.grub.Mechanism". This can be done easily
> already. In fact,
> http://git.fedorahosted.org/git/?p=system-config-boot.git;a=tree;h=experimental;hb=experimental does this.
> 
> What I thought of, is a generic mechanism for _all_ config files with generated action ids. Is this possible?
> Can action ids be generated on the fly, or does every action_id have to be specified in a policy file?
> 

Yes, every action has to be declared in a .policy file. Keep in mind
that, in general, you don't want a ton of different actions - mostly
because administrators need to go through each and everyone of them and
grant/revoke authorizations to users for each.

So for a generic mechanism, you can use the annotation concept as
defined here

http://hal.freedesktop.org/docs/PolicyKit/polkit-conf.html#conf-declaring-actions-annotations

Here's how I expect it to work.

- There's generic org.augeas.Mechanism D-Bus service on the system bus
   - This one is probably just activated on demand etc.

- The UI bits of system-config-boot calls into the mechanism; suppose
   it calls the SetConfigFile ('/etc/grub.conf', new_config_file) on the
   root object / of that service.

- The action for editing the file '/etc/grub.conf', which is
   com.redhat.conf.grub includes an extra tag

   <annotate key="org.augeas.config-file">/etc/grub.conf</annotate>

- You now have the config file '/etc/grub.conf'. Now you need to find
   the PolicyKit action to use. You simple just use the method
   polkit_policy_cache_get_entry_by_annotation (), here

http://hal.freedesktop.org/docs/PolicyKit/polkit-polkit-policy-cache.html#polkit-policy-cache-get-entry-by-annotation

   using annotate_key='org.augeas.config-file' and annotate_value=
   '/etc/grub.conf'.

- Now you know what PolicyKit action to check that the caller has 
   an authorization for. Proceed with checking that the caller has the
   authorization needed

Though. I'm not convinced this is _really_ what you want. But I haven't
yet looked into augeas at all. 

I mean, the ideal API for configuring a boot loader would be very high
level and much tied to how boot loaders work; here's a simple strawman

- The object on / provides method enumerate boot entries as D-Bus
   objects /boot/entry0, /boot/entry1, ... Also provides a way to set
   and get the default boot entry

- Each object /boot/* has a simple interface for setting kernel
   options etc.

It also wouldn't be OS/distro-specific or tied to grub,  yaboot or
whatever boot loader is used. With such an abstract mechanism you'd be
able to reuse the UI on all the distros/OS'es. Which means it has a
honest chance to get into upstream GNOME, KDE, XFCE, E17 etc. releases
and we'll all benefit. 

But maybe this is what augeas gives you? I haven't checked.

(Bad joke: Maybe the GNOME developers will complain that the API is too
complex and it's not easy to build a dumbed down UI around it.
Disclaimer: I'm a GNOME developer myself.)

     David

PS. in com.redhat.conf.grub.policy you probably want to set icon_name as
well. Then you get a pretty icon overlayed on top of the padlock/keys
icon like this

http://people.freedesktop.org/~david/polkit-icon-and-vendor.png

I'd also rename

 com.redhat.conf.grub.access

to

 com.redhat.conf.boot-loader.configure

since that is what the service allows you to do: configure the boot
loader. Then in the future you might want to add support to yaboot etc.