directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] [Created] (DIRAPI-323) Decoding extended operations which require a value isn't enforcing the value to be present
Date Thu, 18 Oct 2018 09:59:00 GMT
Emmanuel Lecharny created DIRAPI-323:

             Summary: Decoding extended operations which require a value isn't enforcing the
value to be present
                 Key: DIRAPI-323
             Project: Directory Client API
          Issue Type: Bug
    Affects Versions: 2.0.0.AM2
            Reporter: Emmanuel Lecharny

Currently, when we decode an extended operation for which we know about (ie, it's registred
in the {{LdapApiService}} instance), and if the {{RequestValue}} part is required, we have
no way to enforce it to be present, which means the decoding will succeed, even if the resulting
extended operation is invalid.

This is due to the fact that the extended operation grammar makes the value optionnal :

        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
             requestName      [0] LDAPOID,
             requestValue     [1] OCTET STRING OPTIONAL }

        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
             COMPONENTS OF LDAPResult,
             responseName     [10] LDAPOID OPTIONAL,
             responseValue    [11] OCTET STRING OPTIONAL }

(works for a request or a response), while for a specific implementation, like the {{CancelRequest}},
defined in [RFC 3909|], the grammar is :

   The Cancel request is an ExtendedRequest with the requestName field
   containing and a requestValue field which contains a
   BER-encoded cancelRequestValue value.

      cancelRequestValue ::= SEQUENCE {
          cancelID        MessageID
                          -- MessageID is as defined in [RFC2251]

and it's clearly not optional.

It boils down to be able to detect the extended operation type (given by the request name,
if present), and then check if the request value is present or not. It's a semantic check,
while the decoding just take care of the syntax, which makes it impossible to detect such
a missing value.

There is a solution for PDU which ends with no controls, as we can tell the grammar that there
is some expected value, which will fail if the PDU ends, but if we have controls, then the
grammar will keep going as some more data is present (we just have to change the {{isGrammarEndAllowed}}
to {{false}} to make that works when no control is present, but obviously that does not work
when we have some controls). 

ATM, I have no solution to this problem. What would be required is to set a flag when we meet
the {{ExtendedOperation}} tag (ie {{0x77}} or {{0x78}}) and check this flag when we have fully
decoded a PDU, but this flag has a semantic meaning, which would break the decoder as a generic
ASN.1 decoder. One solution would be to have the container check itself when we reach the
{{PDU_DECODED}} state in the {{Asn1Decoder}} loop...

This message was sent by Atlassian JIRA

View raw message