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

Alan Pevec apevec at redhat.com
Mon May 9 20:42:10 UTC 2011


(reposting, augeas-devel rejected me at first try)

Hi Radek,
this is an interesting experiment and surely needs some more thought, so I'm adding augeas-devel list to add more eyes.

For augeas developers, Matahari project wiki is https://github.com/matahari/matahari/wiki


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.
>
> The agent is now called _conf_, but some better name would be great :)
>
> Now how the agent works. For now it is only augeas API published to QMF/DBus
> by Matahari agent. First step in using it is to call method `init` which
> return number - handle (ID) of the session. This handle must be then passed to
> all methods (it is an index to augeas structure returned by aug_init()).
> Finally it must be closed by method `close` to avoid memory leaking.
>
> 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.
>
> 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). Second precaution applies only to DBus agent (don't
> know if it is doable with QMF). During init method the handle is connected
> with DBus object name of the caller and all methods check if the caller is the
> same. It might not be an issue for QMF because user must be authorized
> _before_ connecting to the QMF.
>
> Any suggestions are welcomed.

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?

Alan
   
> Radek Novacek
>
>
> [1] https://github.com/rnovacek/matahari_conf
> _______________________________________________
> Matahari mailing list
> Matahari at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/matahari




More information about the augeas-devel mailing list