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
