Jan Vcelak wrote:

...

Sounds like a simple sequencing bug then. Just initialize the global options before the first ldap_initialize() call.

Sudo parses the options in config file and stores them in a table: http://www.sudo.ws/repos/sudo/file/6fa11e8448b9/plugins/sudoers/ldap.c#l225

This table is then iterated and all options are being set. The problem is that some options are set with LDAP handle provided and some are not. This means that the handle has to be created before. The change proposed by you would require the change of this well-arranged and transparent concept.

"Elegance" of code does not make it less wrong.

The config is simply driven as a list. They can very easily fix this so that sudo_ldap_set_options() is called twice, first with a NULL ld and only the non-connection-oriented parameters, then create the LDAP handle and call again to set the connection-oriented parameters.

It can be a sequencing bug, but this particular situation is not described anywhere.

Perhaps that should be raised as a separate doc bug then. Global options are copied to a handle at the time the handle is created. Any options not explicitly set globally at that time are set to their default value.

And OpenSSL has a different behavior. My patch updates Mozilla NSS backend to behave the same as OpenSSL backend.

I still think this should be fixed in OpenLDAP rather than in sudo.

No. Your patch fixes one possible wrong outcome, but the sudo approach is still fundamentally wrong and if we only patch this one instance, someone else in the future is bound to trip over the sequencing problem again. Fix the right bug, otherwise you will have to keep fixing the wrong bugs over and over again.