-----BEGIN PGP SIGNED MESSAGE-----
On 03/30/2011 04:07 AM, Jan Zelený wrote:
I'm sending corrected patches. All your suggestions and objections have been
addressed except maybe for this:
> If the SDAP_SASL_AUTHID has been explicitly set, but the SDAP_SASL_REALM
> hasn't, why are you overriding SDAP_SASL_AUTHID with
I agree with you that the code made a little sense before. I did a little
modification, so the SDAP_SASL_AUTHID isn't changed if possible. Here I'd like
to know your opinion. We might want to prioritize the configuration entered by
admin. My current approach prioritizes an actual content of the keytab if
either SDAP_SASL_AUTHID or SDAP_SASL_REALM isn't entered. That means in case
keytab doesn't contain principal matching the desired one, another one (based
on the preference in select_principal_from_keytab()) is selected.
If the user configuration had absolute priority, there would be a comparison
right after the best principal is selected by select_principal_from_keytab()
and in case the selected principal doesn't correspond to the configured one, an
error should be raised.
What do you think the best approach is for this?
If SDAP_SASL_AUTHID is specified, then ONLY this auth ID is allowable.
If the keytab doesn't contain it, we need to fail.
If SDAP_SASL_REALM is specified, then only the REALM portion is
mandatory (if we have no entries for this realm in the keytab, we need
And for the code review:
If the talloc_strdup() or talloc_asprintf() fails to create the return
values in select_principal_from_keytab(), this should be an ENOMEM
failure. We should not proceed with a value of NULL.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----