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

Attachment: 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

Reply via email to