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
