> masar...@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.
