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.

Thanks,
Simon

> 
> -- 
> Sincerely,
> 
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
> 


Attachment: signature.asc
Description: PGP signature

_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Reply via email to