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.