Re: (ITS#6299) Support for RFC 4529 in slapo-allowed

[masarati@aero.polimi.it]

> masarati@aero.polimi.it wrote:
>>> If the client wants to request via slapo-allowed which attributes are
>>> readable/writeable before adding another object class then object
>>> classes
>>> not
>>> yet part of the entry could be used if the client adds the object class
>>> name
>>> prefixed with @. This is an extension to the semantics but should not
>>> cause any
>>> problem with existing clients.
>>
>> with the current implementation of slapo-allowed, the client does not do
>> anything specific but requesting those special operational attributes.
>
> Yes. That's what I've implemented. Well, what slapo-allowed and MS AD
> implement is limited anyway. E.g. no way to determine writeable attrs when
> adding new entries.
>
>> It is not clear to me how the semantics you propose should be activated.
>> If you mean that having some "@" + <objectClass> in the requested attrs
>> should populate the allowedAttributes and allowedAttributesEffective
>> attributes, I think it would be a significant distortion of the meaning
>> of
>> the requested attributes.
>
> Yes, my suggestion was that slapo-allowed looks at the attr list in the
> search
> request for occurences of "@" + <objectClass>. And then use each
> <objectClass>
> (if not yet in the set of current object classes of the entry) to evaluate
> the
> accompanying attrs and put them into allowedAttributes and/or
> allowedAttributesEffective.
>
> Yes, that's a change in the current semantics.

Not only a change in semantics, but also a poor choice, IMHO.  How can the
server determine whether a request is malformed or the client really
wanted to trigger such an esoteric feature?

> I now partially worked around the problem with new object classes in
> web2ldap
> by determining which attrs would be really new when adding a set of object
> classes enabling all the input fields for these new attrs. But off course
> that's not nice.
>
>> I'd rather favor defining a specific control request, that sort of
>> "mimics" adding some attributes, including objectClass values, to an
>> existing entry, so that allowedAttributes and allowedAttributesEffective
>> are populated accordingly.
>
> There are some implementations of the Get Effective Rights control but
> they
> seem to slightly differ.

That control's definition really sounds like an overkill, although I
understand the intention of allowing clients to specify everything a DSA
could use to determine access privileges.  I'd favor a much lighter
control.  Perhaps, all the features allowed by that spec, and even more
and better (possibly with a flexible mechanism) could be made optional. 
In any case, it should be clear that the result will only be a hint, or a
guess, and the only reliable way to determine read access would be to
actually read data, and, to determine write access, to attempt the
operation using the noOp control.

p.