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.