On 04/25/2011 01:32 PM, Simo Sorce wrote:
> On Mon, 2011-04-25 at 12:12 -0400, Dmitri Pal wrote:
>> This is a problem with the place where we store the configuration
>> it is not replicated. But I am concerned about moving it to some other
>> Any ideas of what would be a "proper" solution to make the change
>> all replicas?
> In order to avoid changing all plugins I am thinking we might create a
> cn=plugin subtree under the shared cn=etc tree.
> And have a new IPA plugin monitor it.
> This plugin will act on any change done to this tree and copy any change
> to the non-shared cn=config tree in order to reconfigure plugins.
> This still leaves open the fact that someone may change directly what's
> in cn=config instead of modifying the shared subtree.
We can create an ACI that will prevent the modification operation to the
managed entry plugin configuration for any user except the internal op.
This will prevent direct modification. Of cause if user removes ACI all
bets are off, but this operation is similar to removing any other ACI
that grants some access or protects some crucial part of the tree. It
prevents customer from erroneously shooting himself in the foot but
would not prevent a suicide if one is so determined...
> Not sure how to cope with that best. One way could be to immediately
> reset back the values to what's in the shared tree, but this means
> intercepting also changes to cn=config.
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-devel mailing list