[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: rename across trees: manageDIT?

At 03:11 PM 8/17/2005, Pierangelo Masarati wrote:
>Luke Howard wrote:
>
>>>One issue I'm finding is that when modifications get to access checking, noUserMod attrs are mixed with the others.  So I'm considering the opportunity to extend the Modifications structure to host a managing flag that's on when the attribute is being managed.  This allows to decide whether a modification should be checked for access.
>>>   
>>
>>Does sml_flags |= SLAP_MOD_INTERNAL not work?
>> 
>I guess this is something slightly different: I want to defer access checking to the time the backend calls acl_check_modlist(); but in that case, noUserMod attrs don't get checked because accerss checking assumes they were internally generated, while they were actually supplied by the user under the umbrella of manageDIT.  So the answer is no, unless I'm missing something.
>
>One thing I was totally missing is that right now manageDIT can only be used by the rootdn identity.  If this limitation is not going to be removed, the entire idea of manage access privilege is going to be useless, and I was finding it quite interesting, because it gives a lot of freedom in delegating fine grained  administration capabilities.

My intent was to make use of ManageDIT require to "manage" rights,
but I hadn't figured out the best way to do this.   Likely just
setting a bit in the modification/attribute and then, when
authorization is checked, require manage (instead of write).

Kurt