Re: LDAP_OPERATIONS_ERROR instead of LDAP_INSUFFICIENT_ACCESS (ITS#1987)

[michael@stroeder.com]

Kurt D. Zeilenga wrote:
> 
 >>>2.1 includes operations error checks which previous versions
 >>>didn't.
 >>
 >>Can you elaborate on this? Which checks.
 >
 > Actually, I was incorrect.  2.0 returned operationsError in this
 > case as well.  Not sure when it was back ported, I presume after
 > the version you were using.

I usually do a cvs up -RdP weekly or sometimes even daily. Is that 
recent enough? I checked now and REL_ENG_2 returns 
insufficientAccessRights with info "no write access to parent". 
That seems reasonable to me.

Hmm, it also seems to have nothing to do with whether access 
control rules are present in the configuration or not.

>>>>In OpenLDAP 2.0.x and any other LDAP server I know of LDAP_INSUFFICIENT_ACCESS
>>>>is returned if the add or modify operation fails.
>>>
>>>insufficientAccess indicates that the operation failed
>>>due to violation of the access control policy.
>>
>>Which makes sense in that case either. Doesn't it?
> 
> No.  Because the operation is not being disallowed as
> a matter of access policy.  Protocol restrictions are
> not viewed as access policy (even if configurable).

Again: Note that a BindRequest was sent before => the protocol 
operation sequence is not violated. 2.1 treats anon bind as you 
would never have received a BindRequest. That seems like a bug to me.

IMHO in this case insufficientAccessRights is the right error code 
since anonymous is not allowed to write.

> Now, it could be argued that strongAuthRequired would
> be a more appropriate result code in this case.

???

 From draft-ietf-ldapbis-protocol-07:
--------------------------------------------------------------
    - strongAuthRequired: the server requires authentication be
      performed with a SASL mechanism.
--------------------------------------------------------------

I don't think that this is the right error code.

>>>>But OpenLDAP 2.1.x returns LDAP_OPERATIONS_ERROR with info field saying
>>>>"modifications require authentication".

Im my situation the client is already authenticated. Well, 
anonymous, but authenticated.

> draft-ietf-ldapbis-protocol describes operationsError as:
> 
>>       operationsError (1) 
>>          Indicates that the operation is not properly sequenced with
>>          relation to other operations (of same or different type).    
> 
>>The new way in OpenLDAP 2.1.x does not allow write operations for anonymous bind at all?
> 
> The restriction can be disabled (like most of the restrictions),
> but, yes, 2.1 is designed to disallow all anonymous updates
> regardless of access control policy.

And I would classify this restriction as (reasonable) access control.

>>Note that my client does the anonymous bind explicitly before any other operation (except StartTLS extended operation) for probing LDAPv3 vs. LDAPv2.
> 
> I think it odd that you attempt an update operation while
> anonymous.

Why? It's very user-friendly. The user can browse anonymously and, 
if required, bind with higher-privileged Bind-DN. Well, the user 
should login before but usually forgets it. That works for me all 
day for access control restrictions.

>>>>This is bad since LDAP_OPERATIONS_ERROR can be anything
>>>
>>>No!  The operationsError resultCode indicates an operations error,
>>>which has specific meaning in LDAP
>>
>>Fact is that it's a common practice with LDAP servers to return LDAP_INSUFFICIENT_ACCESS and that it's pretty convenient for the user getting a login form instead of generic operations error message.
> 
> Not sure what you mean by "generic" here.
 >  OperationsError is
 > actually quite specific.  It reports a problem due to how this
 > operation relates to other operations. (Hence the "s" in
 > operationsError).

"Generic" means that the application is unable to figure out which 
protocol sequence was violated.

>  And, IIRC, I've seen other servers return
> codes other than insufficientAccess in this case.

Which one?

>  I won't be
> surprised to find strongAuthRequired or unwillingToPerform here
> as well.

unwillingToPerform is sometimes used on old LDAPv2 servers or 
something shitty like ldap.bigfoot.com.

>>The new way in OpenLDAP 2.1.x makes the life of LDAP application programmers even more miserable than it already is.
> 
> Would changing this to strongAuthRequired help?

No, since it would mandate a SASLBindRequest.

Ciao, Michael.