Re: (ITS#5872) slapo-cloak

[hyc@symas.com]

ando@sys-net.it wrote:
> michael@stroeder.com wrote:
>> ando@sys-net.it wrote:
>>> Hallvard B Furuseth wrote:
>>>> ando@sys-net.it writes:
>>>>> On a related note, if this can be considered of general usefulness, LDAP
>>>>> specs would need to be changed in order to define a finer grain of
>>>>> attribute request; something like:
>>>>>
>>>>> empty or "*" ; all user, except attrs that need to be explicitly req.
>>>>> "+" ; all operational
>>>>> <all including attrs that need to be explicitly requested>
>>>>> <...>
>>>> Would it be cleaner if slapo-cloak redefines the attributes to be
>>>> operational, or to behave as if they are?  Maybe give them an
>>>> X-AS-OPERATIONAL extension?  Or would that just mess up schema code,
>>>> things like attribute inheritance?
>>> I think things would mess up.
>> I'd also recommend *not* to turn user attribute types into operational
>> attribute types. This would certainly confuse schema-aware clients.
>>
>>> Moreover, I see a number of features system administrators could ask
>>> for; e.g. hide attributes only when matching a URI (base, scope,
>>> filter),
>> Well, that's something many overlays would benefit from.
>
> In fact, based on recent modifications to slapo-constraint(5) and other
> overlays, I'm considering the opportunity to introduce generic helpers
> to parse and check this type of generic limitations.

We've discussed this before - overlays ought to have a configurable range of 
effect, using an X.500 Subtree Search Specification.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/