Full_Name: Michael Str�der Version: HEAD OS: URL: Submission from: (NULL) (84.163.118.158) 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.
> 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. 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. 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. p.
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. 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. Ciao, Michael.
> 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.
moved from Incoming to Software Enhancements
does not provide reliable answer to the query, needs a solid use case and workable solution.