[augeas-devel] [Matahari] Augeas-based configuration agent

[David Lutterkort]

On Mon, 2011-05-09 at 22:42 +0200, Alan Pevec wrote:
> On 05/09/2011 11:44 AM, Radek Novacek wrote:
> > I finally published augeas-based agent. You can find it in my repo on github
> > [1]. It is now done as standalone agent out of matahari tree, but it should be
> > easy to integrate it into Matahari.

Very nice :)

> > Since those method aren't stateless there are some security issues. For
> > example: User creates his session, change some files and saves (after
> > authorization check by polkit). But all DBus communication is public, so
> > anyone can use same handle to changed other files before user saves. All
> > changes will be saved no matter who did them.

That's a serious concern, since that gives anybody write access to large
swaths of the file system.

> > To aviod this issue two precautions were made. Init takes name of augeas' lens
> > as argument  and won't load any other lenses. It should minimize the impact of
> > this issue, but it's a little bit hackish and user unfriendly (need to know
> > the name of the lens).

If you expose the entire augeas API, it also won't keep people from
modifying random files; all they need to do is set up transforms
under /augeas/load themselves, and then do an aug_load.

A cleaner solution would be to add functionality to restrict what a user
can modify. For example, we could add the convention that we respect a
list path expressions underneath /augeas/restrict; if there is anything
in that subtree, the user will only be allowed to read/write parts of
the tree that match. For example, we could do

        clear /augeas/restrict  # Set to NULL so that checking is turned off
        rm /augeas/restrict/*
        set /augeas/restrict/incl /files/etc/hosts
        set /augeas/restrict/incl /files/etc/inittab
        set /augeas/restrict/incl /augeas/files
        set /augeas/restrict enforce

After this, the user would only be allowed to read/write/modify the
subtrees /files/etc/hosts, /files/etc/inittab, and /augeas/files

> I would avoid state by not publishing direct augeas API.
> Instead, why not accept a list of changes and perform it atomically in one call?

That's what the augeas type for puppet does[1] It takes a string with
augtool-like commands, executes them and then saves the resulting tree.
Since this has now been implemented twice (in Ruby for puppet, in C for
augtool) it might be time to move that functionality into the Augeas API
proper.

David

[1] http://projects.puppetlabs.com/projects/1/wiki/Puppet_Augeas and the
changes param documented at
http://docs.puppetlabs.com/references/latest/type.html#augeas