-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/30/2011 04:07 AM, Jan Zelený wrote:
Hi, 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 select_principal_from_keytab()?
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 to fail).
And for the code review:
Nack. 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.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/