On Tue, 2011-05-10 at 09:11 +0200, Andrew Beekhof wrote:
On Mon, May 9, 2011 at 11:00 PM, David Lutterkort
<lutter(a)redhat.com> wrote:
> On Mon, 2011-05-09 at 22:42 +0200, Alan Pevec wrote:
>> On 05/09/2011 11:44 AM, Radek Novacek wrote:
>>
> 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
Could an attacker not simply add files to that list?
The idea is that as soon as /augeas/retrict is set to a non-NULL value,
you can only modify paths that are explicitly allowed, i.e. you can't
modify /augeas/restrict anymore, either.
>> 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.
Sounds like a good path forward.
Would it make sense to borrow the augtool C code until it makes it
into the proper API?
I was hoping somebody would just cook up a patch based on augtool ;) It
shouldn't be much more work than doing it (yet again) for standalone
use.
David