[Date Prev][Date Next]
Re: (ITS#6299) Support for RFC 4529 in slapo-allowed
> firstname.lastname@example.org wrote:
>>> If the client wants to request via slapo-allowed which attributes are
>>> readable/writeable before adding another object class then object
>>> yet part of the entry could be used if the client adds the object class
>>> 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
>> the requested attributes.
> Yes, my suggestion was that slapo-allowed looks at the attr list in the
> request for occurences of "@" + <objectClass>. And then use each
> (if not yet in the set of current object classes of the entry) to evaluate
> accompanying attrs and put them into allowedAttributes and/or
> 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
> 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
> 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.