Control: tag -1 upstream moreinfo
Control: severity -1 normal
Hello,
Thank you for the report, and sorry for not answering sooner.
On Mon, Dec 14, 2015 at 03:05:22PM +0100, Obspm wrote:
From a fresh install (the server is a virtual machine with VirtualBox), after
basic configuration of slapd, without any configuration other than those make
by apt-get, with no special data I can add this piece of ldif
dn: cn=config
changeType: modify
add: olcTLSVerifyClient
olcTLSVerifyClient: never
-
I always got a
root@debian:~# ldapmodify -Y EXTERNAL -H ldapi:/// -f toto.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
At the moment, I think this behaviour is intentional and by design.
First, I would note that this only happens when you haven't performed
the minimal TLS configuration yet:
http://sources.debian.net/src/openldap/2.4.40%2Bdfsg-1%2Bdeb8u1/libraries/libldap/tls2.c/#L199-L202
In this case, "unwilling to perform" means that the change can't be
applied and take effect immediately, because TLS isn't even active yet.
After you configure a server certificate or CA certificate, then you can
start setting TLS options.
You could argue that the change should be accepted and committed, as if
it had been done offline, and saved for when TLS is next started. (I say
"change" here intentionally, even though the value in your example is
the same as the default.)
There is room on either side, to argue that a more informative error
message could be returned along with the error code, or that there is
precedent for cn=config changes that are accepted but not applied until
some subsystem, or slapd itself, is restarted. I don't have any
particular opinion on any of this, and would rather not argue with
upstream about design choices.
I am not forwarding this upstream right now, but I'd be willing to, if
you can say a few more words about how you think this should behave and
why. Alternatively you could open a report yourself at
http://openldap.org/its; if you do that, please link the report here.
thanks,
Ryan
