[SSSD] [RFC] Use of DP_ERR_* codes

Jakub Hrozek jhrozek at redhat.com
Fri Nov 6 15:21:50 UTC 2015


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...

> 
> 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?


More information about the sssd-devel mailing list