Howard Chu wrote:
Peter Mogensen wrote:
Mike Malsman wrote:
On 11.Mar.2009, at 9:32 AM, Peter Mogensen wrote:
But limiting cn=config access to ldapi:/// ... no luck.
Of course, I have to add a "userPassword" attribute to cn=config.ldif, but it seems to be ignored.
It ought to be rejected/startup should fail; userPassword is not a valid attribute for any cn=config entries.
I guessed so.
Personally I think peername-based access control is a crock. For TCP sockets, IP addresses can be easily spoofed. For Unix Domain sockets, different operating systems have different policies on how/whether Unix permission bits affect them.
Yes - but limiting access (say cn=config, if it was possible) is an explicit statement by the sys-adm (me) that I want configuration access to be governed by OS permissions on _this_ installation. That's no different from the old slapd.conf
The only safe thing to do is assume that any user can access the socket, because that's almost universally true.
But there was no assumption that any user could write to slapd.conf. Wasn't the assumption that the sysadm had to control configuration access external to the database?
Do it right, use SASL/EXTERNAL and use authz-regexp to map Unix credentials to LDAP credentials.
And don't mess around with "userPassword" when "rootpw" is what you need.
won't setting a rootpw allow anyone being able to guess it to connect on any socket (TCP/UNIX) that slapd is listening on an bind as cn=config?
/Peter