https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #15 from Ondřej Kuzník <[email protected]> --- On Mon, Jun 12, 2023 at 01:15:21PM +0000, [email protected] wrote: >> You can always make this the first ACL in the list (in your analogy, >> putting a security guard/gate that checks people even get access to the >> building): >> >> access to * by <your allowlist expressed as peername/sockname> break by * >> none > > An awful lot of lines of code need to run to parse and interpret the ruleset, > and parse and interpret LDAP commands, seems how the ruleset isn't applied > until it is presented with a command. I'm not saying there IS anything wrong > with that code, I just don't know. And I have the option of putting a proxy in > front of it and then I can sleep better. Slightly off-topic but if you configure ldaps:// and *require* client certs, the session won't get set up to the point of touching anything LDAP related until the client's proved it holds a certificate you trust. That's more or less what you're using haproxy for? If so, I think you're in the clear even if you don't wish to trust the ACL machinery is being completely and consistently enforced. >> Except that rereading the spec, we don't actually get to see the whole >> DN, just the CN part so that is not viable unless a new field were >> defined for it. > > Yeah, I was worried about that too. Luckily for me at least, My client > certificate's DN's only have a single CN - so no information lost. I'm sure > this is not true in general. But so long as the CN's are unique, I could use > the DN rewriting to fill in all the missing RDNs. Well, that by itself doesn't sound like enough for the OpenLDAP side, hence the need for a new field. -- You are receiving this mail because: You are on the CC list for the issue.
