Re: [ldapext] comment control, dummy request, no-response request

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>At 02:30 PM 2/22/2005, Hallvard B Furuseth wrote:
>>"Comment" control:
>>
>> It can be useful to attach a comment to an LDAP request.
>
> For what purpose?  Tracing or other?

That's the use which prompted this suggestion, yes.

> (...)
> (The point of me asking the above question is to have you
> narrow the purpose of the control to one thing.)

I was thinking in just the opposite way: Make the wording reasonably
general and not a "just for me" control, as long as it's basically a
no-op:-)

> (...) I suggest you call it the "trace" control (a control which
> provides "trace information).  I can see providing trace information
> useful in a number of applications, namely in testing.

Right.  Will do.  In fact, I grumbled over the name "comment" because
that didn't quite say what I wanted.

>> I'm not sure how to define the controlValue, though.
>
> I would suggest the controlValue as holding an LDAPString
> providing arbitrary trace information.
>
>> Usually an LDAPString would be natural, but sometimes one may
>> want to attach data with no defined or known character set.
>
> Hmmm... if more information than a character string is desirable,
> I'd argue that the application being served likely should use
> a different control specifically designed for its needs.

I disagree with that, but after writing up the reason I ended up
agreeing with LDAPString anyway:-)

I disagree because one wants to log enough data to analyze what's going
on.  In my case I expect to log web search number, anonymized user ID,
user IP address and search string.  That can of course be encoded as an
LDAPString, but it is really data, not just text.  Or one might want to
log the exact user input for a search with its original character
encoding.  Transforming to an UTF-8 LDAPString can lose information.

However, after all a log is normally textual, so the trace info must be
represented as text in the log.  The client could just as well make it
textual as the server, e.g. base64-encode any raw data.  That keeps it
simple, and doesn't leave the server implementor wondering if it would
be good to sometimes log the trace info in base64 instead of as a
string, or whatever.

>> So a plain OCTET STRING might
>> be better, to be interpreted at the server admin's discretion.
>
> I rather say that the information provided is to only be used
> for trace purposes and is not to be otherwise interpreted or
> used.

While I'd like to say somehow that the trace info is to have no "real"
effect (your "not otherwise...used"), I'm a bit leery of that.  I was
thinking more of something like "is not intended to be otherwise
interpreted or used".

E.g. the server itself could do some of the testing you mentioned and
react to the results.  Though in that case I don't suppose it's a
problem when a server during testing doesn't act quite according to the
spec.

After the talk about dummy operation + access controls, I've realized
that there should be configurable restrictions on this control, maybe a
form of access controls.  Otherwise anyone could spam the log with
massive trace info.  Normal access contols are no help, since failed
operations should still log the trace info.


>> "Dummy" extended operation:
>>
>> Has anyone defined a dummy extended operation, which does nothing except
>> whatever the attached extensions say? If not, would anyone else like to
>> see it defined?
>
> I am not sure this makes sense, which I will illustrate below.
>
>> A client can want do issue a request solely for the sake of the attached
>> controls.  To enter a note in the log with the "comment" control.  To
>> test if the currently bound user can proxy for a given authorization ID
>> with the Proxy Authorization Control (draft-weltman-ldapv3-proxy-12.txt).
>
> Well, say there was an operation which did nothing.  A server
> might allow anyone to do nothing, and allow anyone to proxy as
> anyone as long as nothing was being done.  That is, the authorization
> model may only have an impact when something is being done,
> or some piece of information is being accessed.

I don't see the problem with that when it does nothing.

If it does something due to attached controls, those controls should be
subject to access controls.  But that's true for the controls if they
are attached to other operations as well, so it doesn't seem different.

Except there might be controls that do something which does not fit the
server's access control model, so one can only prevent them by
preventing all operations they are appropriate for.  StartTLS could have
the same problem, since that doesn't act on any entry either.  If so,
one could suggest that servers may use access restrictions on the dummy
operation if they want, e.g. "detect" access if that is implemented, and
use some arbitrary DN configured by the server for access control if no
DN is provided with the request.

> And, in particular, the user cannot assume simply because:
>         nothing+proxied(u:foo)
> was successful that:
>         something+proxied(u:foo)
> will not fail (with any error specific to the proxied authorization
> control, or otherwise).
>
> That is, one cannot (in general) reliably use the results of one
> operation to predicate the outcome of another operation.
> A notable exception (with limitations and caveats) is an operation
> with noop v. that operation less no-op.

True enough.  The noop control can test if a particular operation will
work, an authorization test can indicate that a group of operations will
surely fail.  And the user may know the particular directory well enough
to be aware that if the test doesn't fail, he should have access to the
other operations.

>> To use the "assert" control (draft-zeilenga-ldap-assert-05.txt) if one
>> wants to check an entry against a filter and the compare operation is
>> insufficient.  Using "assert" instead of baseobject search avoids one
>> returned PDU.  I suppose such an operation could at times also be useful
>> to keep the server from timing out the LDAP connection.
>>
>> ExtendedRequest.requestValue, if present, would be an LDAPDN packed in
>> the requestValue OCTET STRING, so that controls that act on a DN will
>> know which DN to act on.
>
> Why not just use a compare(dn,ObjectClass,"top")?

Mostly just for clarity (e.g. in the log) and efficiency, though one
might lack access to compare objectClass or the entry itself.  Just as
I've seen searches for "(objectClass=*)" find nothing where "(&)"
succeeded.

(For the Trace control, compare(dn="", attr="1.1", val="") might be
preferable if there is no dummy operation: It's clearly not trying to
do anything sensible.  Or abandon(msgid=0), as I mentioned before.)


>> "No-response, dummy" operation:
>>
>> This one is pretty marginal.  I could define such an operation too if
>> anyone feels a need for it, but otherwise I won't bother.
>>
>> For use with the comment control, it could be convenient with a dummy
>> operation which did not return a response.  I can't think of other
>> instances to desire a dummy no-response operation at the moment.
>>
>> ExtendedRequest does not support no-response operations.
>
> A specification is free to utilize ExtendedRequest in design
> of a no-response operation.  It would not be an "Extended Operation"
> as defined in [Protocol], as that described as having a response.
> But there is no text in [Protocol] that precludes the use of
> ExtendedRequest in design of response-less operations.

Not that I can see.  RFC 2251 says:

   The server will respond to this with an LDAPMessage containing the
   ExtendedResponse.

>> One could define a new request type, or fake it with abandon of an
>> unused message ID (e.g. msgID 0), or define a critical control which
>> cancels the effect of Abandon.  Kurt's "noop" control could be
>> extended to be used with Abandon, but that would probably only be
>> useful with no-effect controls like "comment".  So that usage seems
>> even more marginal.
>
> I think it generally unwise to attach semantics onto
> operations created through use of controls which are not
> consistent with the base operation.

True enough.

> Seem you'd need a new operation here.

Only if anyone sees a greater need for it than I do:-)

-- 
Hallvard

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext