Visitar URL original
store option-invalue tuple only after successful set_option call by lu-kno · Pull Request #696 · python-ldap/python-ldap · GitHub
Skip to content

store option-invalue tuple only after successful set_option call - #696

Open
lu-kno wants to merge 1 commit into
python-ldap:mainfrom
lu-kno:bugfix/ldap_object_options_list_on_error
Open

lu-kno wants to merge 1 commit into
python-ldap:mainfrom
lu-kno:bugfix/ldap_object_options_list_on_error

Conversation

@lu-kno

@lu-kno lu-kno commented Nov 5, 2026 •

Copy link
Copy Markdown

LDAPObject.set_option should only append to the stored LDAPObject._options list of tuples if the SimpleLDAPObject.set_option call within didn't raise an error.

Example code (using GnuTLS):

connector: ldap.ldapobject.ReconnectLDAPObject
user_dn: str
password: str

(...)

try:
    # OPT_X_TLS_CRLCHECK is only valid for OpenSSL
    # connector.set_option stores the option-invalue tuple in connector._options
    # then attempts to set it with ReconnectLDAPObject.set_option
    connector.set_option(ldap.OPT_X_TLS_CRLCHECK, ldap.OPT_X_TLS_CRL_NONE)
except ValueError:
    # ReconnectLDAPObject.set_option raises a ValueError when using GnuTLS 
    # This Exception is expected and can be safely ignored
    pass

# OPT_X_TLD_CRLCHECK tuple is still stored in conn._options, 
# even if the ValueError was raised
(...)

try:
    # connecting to a Server that is down
    # this calls self._apply_method_s
    # which throws an ldap.SERVER_DOWN exception
    # which is handled within _apply_method_s by calling self.reconnect(..., force=True)
    # which calls self.restore_options
    # which calls self.set_option for the tuples in self._options
    # which raises ValueError
    connector.simple_bind_s(user_dn,password)
except ldap.SERVER_DOWN:
    # handle exception if the server is down
    pass
except ValueError:
    # this is should not have been raised here
    raise

Calling SimpleLDAPObject.set_option can raise an error.
option-invalue tuple should only be appended to self._options if no Exception occurred

@droideck droideck left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should hold _reconnect_lock across the base setter and successful append, initializing it before SimpleLDAPObject.__init__...
A concurrent reconnect can replay the old history between these lines, so setting the network timeout to 0.25 succeeds while the replacement connection retains 10.0. I reproduced this through automatic reconnect after a slapd restart; the previous ordering preserves 0.25.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants