Re: Config attribute - nsslapd-allowed-sasl-mechanisms - behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux