Pierangelo Masarati wrote:
The point is that there used to be (and there is, I haven't committed recent fixes yet, since I'm trying to convince myself that everything is now fixed :) some confusion about those special identities. What I came out so far is that in the internal handling of those special connections:
- privileged connections are treated some way
- idassert connections are treated separately
- in case a connection ought to be privileged, but acl-bind is not set
and idassert-bind is set, the latter identity is used for privileged connections as well
I'm not 100% convinced about (3), though, because that would obfuscate what identity is used for what purpose. The reason for (3) is that if one doesn't need to have privileged connections, he shouldn't set acl-bind at all; however, there might be cases where one wants to have identity assertion in place, and if acl-bind is not configured, connections as the rootdn wouldn't exploit it (this may happen, for example, when using slapo-chain(5) on top of a database that needs to have the rootdn in place).
So the point is: is it preferable to explicitly configure twice the same identity, or have a "sane" default if one only sets idassert-bind and not acl-bind? All in all, the identity that's used for identity assertion is not likely to be more privileged than the privileged one...
Perhaps just use a new acl-bind keyword that means "same as idassert" ?
This is has definitely been a confusing area. I've been working on adding per-instance TLS configuration support here, and I wasn't quite convinced how many separate TLS contexts were needed. Your email helped clarify things, thanks.
Also on the topic of separate TLS contexts - currently the main slapd TLS context is only used for incoming connections. The syncrepl consumer and any other outbound connections use the TLS info in ldap.conf by default, not slapd.conf. Some folks have suggested that it makes more sense for the default to come from the main slapd settings instead. Any thoughts on that?