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