On Sun, 2017-04-23 at 22:28 +0200, Simon Pichugin wrote:
On Fri, Apr 21, 2017 at 04:02:50PM +1000, William Brown wrote:
> On Fri, 2017-04-21 at 07:55 +0200, Simon Pichugin wrote:
> > On Fri, Apr 21, 2017 at 09:25:23AM +1000, William Brown wrote:
> > Partly, yes. My question was about possible regression.
> >
> > We have a lot of tests for nsslapd-allowed-sasl-mechanisms in TET.
> > It has raised two concerns I have now.
> >
> > First, if we are trying to set 'empty value' with a replace operation,
it fails (and it is okay).
> >
> > But now with your new cn=config feature we have
'nsslapd-allowed-sasl-mechanisms' empty by default.
> > It seems to be wrong as long as the servers forbids to set 'empty
value' manually.
>
> Well, the bug there is we can't set an empty value. You should be able
> to delete the attribute though, and that should reset it.
>
> Additionally, it may be worth checking that if the value is empty sasl
> treats that as *all* mechs are allowed. This would be one of the few
> config items where I think it should be a blacklist, rathar than
> whitelist.
>
> So certainly, this could be a bug.
>
> >
> > Second test that fails now asserts that we can't add more values to the
> > single-value attribute (nsslapd-allowed-sasl-mechanisms is the one).
> > The test excpects an error. But the server just replaces the value with
> > a new one. No error happens. Is it by design or we should fix it?
>
> I did fix some code related to add/replace. I think that if you add
> another value, and it replaces, that's a bug. It contradicts the ldap
> standard I think.
Hi William,
after some investigation I've found out that my previous report was
misleaded by TET. Though I've found some strange behaviour in the
cn=config reset to defaults feature and the subject.
On clean instance:
1. Check the supportedSASLMechanisms on a clean instance with a default
nsslapd-allowed-sasl-mechanisms:
[root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=directory
manager" -w Secret123 -b "" -s base supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: ANONYMOUS
2. Set some particular SASL mechanism:
[root@qeos-236 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D "cn=directory
manager" -w Secret123
dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms: DIGEST-MD5
modifying entry "cn=config"
3. Check the supportedSASLMechanisms:
[root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=directory
manager" -w Secret123 -b "" -s base supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
4. Reset to default by deleting the attribute:
[root@qeos-236 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D "cn=directory
manager" -w Secret123
dn: cn=config
changetype: modify
delete: nsslapd-allowed-sasl-mechanisms
modifying entry "cn=config"
5. Check the supportedSASLMechanisms once againg:
[root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=directory
manager" -w Secret123 -b "" -s base supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
6. Restart the instance:
[root@qeos-236 dirsrv-tet-install]# restart-dirsrv
Restarting instance "qeos-236"
7. Check the supportedSASLMechanisms:
[root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=directory
manager" -w Secret123 -b "" -s base supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: ANONYMOUS
Results: So if we reset the attribute it will not be applied without a restart.
Though if we set some SASL mechanism manually it will be applied instantly.
Ahhh, so the issue is in how we reset this value to a default. Okay,
that is a bug. Do you mind opening an issue an assigning it to me?
Should be relatively easy to resolve.
Do you have a lib389 testcase? Or is this tet?
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane