Hi [2026-06-20 18:42] "Andrea Pappacoda" <[email protected]> > Over the last few days I've been trying to implement K_AUTH support in > table_ldap.c, since I need it in my new email server setup. While I now > have a better understanding of the code, I still haven't managed to > complete the implementation, and I'm now reaching for help.
Nice I haven't had enough time to do this. > The way K_AUTH should work with LDAP is that for each check|auth request > table-ldap should issue a bind to ldapd with the appropriate pair of > username and password. > > Currently, table-ldap relies on a global struct aldap instance to talk > with ldapd, initializated and bound at startup. This works fine now, but > I believe it cannot be used for K_AUTH. This is because bind requests > have special semantics as described in RFC 4511 ยง4.2.1, which says: > > > Before processing a BindRequest, all uncompleted operations MUST > > either complete or be abandoned. The server may either wait for the > > uncompleted operations to complete, or abandon them. The server then > > proceeds to authenticate the client in either a single-step or > > multi-step Bind process. Each step requires the server to return > > a BindResponse to indicate the status of authentication. > > > > After sending a BindRequest, clients MUST NOT send further LDAP PDUs > > until receiving the BindResponse. Similarly, servers SHOULD NOT > > process or respond to requests received while processing > > a BindRequest. > > So I though of adding another struct aldap instance, named aldap_k_auth, > used exclusively for binds needed in K_AUTH requests. This should be > fine as the same section quoted above continues with: > > > Clients may send multiple Bind requests to change the authentication > > and/or security associations or to complete a multi-stage Bind > > process. Authentication from earlier binds is subsequently ignored. > > The issue with this, though, is that all the code assumes there's really > just one aldap instance. This could of course be changed, but I'm first > asking here for advice as to how it'd be better to continue. This is the same as I have planed to implement K_AUTH. This of course needs some restructuring. > My biggest question is related to table_api_register_fd(), which is > called with aldap's fd and the ldap_fd_callback function. I'm not too > familiar with libevent; is it possible to call it twice, passing > aldap_k_auth's other fd? Is it even a good idea? This is what the table_api_register_fd was designed for. You just need to hanlde the correct aldap struct (or use a different callback). If you like you could also just implement K_AUTH blocking and we later look how to implement it nonblocking. Philipp
