[SSSD] [RFC] Use of DP_ERR_* codes

Pavel Březina pbrezina at redhat.com
Fri Nov 6 15:40:03 UTC 2015


On 11/06/2015 04:21 PM, Jakub Hrozek wrote:
> On Fri, Nov 06, 2015 at 03:51:30PM +0100, Pavel Březina wrote:
>> Hi!
>>
>> Since we have pretty nice custom error codes, I would like to get rid of
>> DP_ERR_* codes. They are practically useless and are adding non-trivial
>> complexity to the code.
>>
>> I did only a quick look so it is possible that I missed something, but let's
>> talk about it. We have the following codes:
>>
>>> #define DP_ERR_OK 0
>>
>> DP_ERR_OK is usually used in combination with EOK and in most cases it is
>> treated as error (or worse not handled at all). There are some situations
>> when DP_ERR_OK and !EOK is used, it is mostly in combination with PAM error
>> code and access control, but we can handle this with custom error codes.
>>
>>> #define DP_ERR_OFFLINE 1
>>
>> DP_ERR_OFFLINE means EAGAIN, always. This should be changed to ERR_OFFLINE
>> or similar custom error o
>
> This error code can't be returned from provider's can it?
>
>>
>>> #define DP_ERR_TIMEOUT 2
>>
>> This is not used at all.
>
> I guess this was meant to be used for cases where the DP takes too long
> to answer and the request is cancelled.
>
>>
>>> #define DP_ERR_FATAL 3
>>
>> This is other than EOK code and should be avoided.
>>
>> Having only one error code from sdap operations would simplify code flow and
>> make the code less error prone.
>
> I don't think we should leak sdap error codes to responders (and data
> provider is mostly a layer between responders and providers). The
> authentication code currently returns PAM error codes to DP..
>
> What if the provider returned a single error code but we still retained
> a tuple of (dp_err, provider_err) towards the responders? Then DP_ERR_OK
> and DP_ERR_OFFLINE wouldn't use the minor error code but DP_ERR_FATAL
> would transfer the error from the provider along with sss_strerror()
> or similar explanation?
>
> Then providers would return a single error code, but responder would
> be able to distinguish between cases where all went fine, where provider
> wasn't even contacted and failures...

Yes, this makes sense.

>> In my opinion this should be part of or even prerequisite to ldap provider
>> and sdap_id_op refactoring.
>
> How is DP interface related to sdap_id_op code?

dp_err is in most cases generated in sdap_id_op and than bubbles up. If 
sdap_id_op doesn't use it, we can get rid of most of its references.





More information about the sssd-devel mailing list