On Thu, 2017-04-20 at 22:54 +0200, Simon Pichugin wrote: > Hello William, > I think my question is for you in the first place. > It regards the default attributes for cn=config feature. > > Version tested: 389-ds-base-1.3.6.1-9.el7.x86_64 > > During TET troubleshooting I've faced two issues: > 1. By default, we have: > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D > "cn=Directory manager" > -w Secret123 -b "cn=config" "objectclass=*" | grep > nsslapd-allowed-sasl-mechanisms > nsslapd-allowed-sasl-mechanisms: > > Empty value. > > We can modify it and set something. (I'll skip the output, it works as > expected. > And after this, the server allows to do like this: > [root@qeos-126 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" > > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D > "cn=Directory manager" > -w Secret123 -b "cn=config" "objectclass=*" | grep > nsslapd-allowed-sasl-mechanisms > nsslapd-allowed-sasl-mechanisms: >
> Pretty sure the SASL mechs can't be written to: they are returned from https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/saslbind.c#_754 And that only allows setting from mechs discovered by cyrus-sasl, and mechs that are from plugins that register to slapi_register_supported_saslmechanism() . The allowed mechs parameter is the list that is checked to see if we'll allow using it, and that's called from ids_sasl_getopt. During the set in libglobs, it looks like we check that the mech is a real name supported by SASL, so perhaps test with values like PLAIN, GSSAPI instead? > > 2. Second one is a known issue, but still I'd like to clarify the expected > behaviour: > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D > "cn=Directory manager" > -w Secret123 -b "cn=config" "objectclass=*" | grep > nsslapd-allowed-sasl-mechanisms > nsslapd-allowed-sasl-mechanisms: A > [root@qeos-126 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D > "cn=Directory manager" -w Secret123 > dn: cn=config > changetype: modify > add: nsslapd-allowed-sasl-mechanisms > nsslapd-allowed-sasl-mechanisms: B > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D > "cn=Directory manager" > -w Secret123 -b "cn=config" "objectclass=*" | grep > nsslapd-allowed-sasl-mechanisms > nsslapd-allowed-sasl-mechanisms: B > > So it wouldn't be a multivalued attribute? if we'll do the 'add' operation, > it would replace the existing value with a new. > > Please, comment of a both cases. First looks more like a bug to me though, > and I will file it if you'll confirm it. Anyway, it looks like in libglobs.c, that it expects a comma seperated list, it's not multivalued. The reason is that this single attribute is returned in config_get_allowed_sasl_mechs(); during the ids_sasl_getopt call, which SASL_CB_GETOPT expects a specific format. I imagine this is because it's easier to store it as one line in the config, and requires less parsing each SASL request to go from multivalue to one line, so it's an efficiency thing. Does that help explain the answer to your problems? -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
