Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.14 beta

Fields changed

rhbz: => todo

Nice to have for 1.14

milestone: SSSD 1.14 beta => SSSD 1.14 backlog

Fields changed

keywords: => easyfix

Since the 1.14 branch is transitioning into maintenance mode and new functionality is being developed in master which will become 1.15 eventually, I'm mass-moving tickets from the 1.14 backlog milestone to the "Future releases" milestone.

milestone: SSSD 1.14 backlog => SSSD Future releases (no date set yet)

Hi,

I've been having a look at this issue and I have several questions related with it:
1- What should be the "special error" code that should be returned by cache_req_single_domain_recv function? I have been having a look at the errno definition and the one that best suits it is EPERM, but maybe you are thinking about a new one.
2- How should the client manage the error? Is it enough with the actual checks or should I add a new one to indicate that there are two possible entries?

Hi,
I've been having a look at this issue and I have several questions related with it:
1- What should be the "special error" code that should be returned by cache_req_single_domain_recv function? I have been having a look at the errno definition and the one that best suits it is EPERM, but maybe you are thinking about a new one.

Yes a new one , please src/util/util_errors.h for "special errors"

2- How should the client manage the error? Is it enough with the actual checks or should I add a new one to indicate that there are two possible entries?

The infopipe (IFP) responder should send the error code and a message back to the caller via DBus, see src/sbus/sbus_errors.c how this is handled.

bye,
Sumit

Hi Sumit,

Thank you very much for your answer. I've taken into account you comments, then I've been digging on the code and I have found another problem. Function sbus_errno_to_error() fulfills an error name and a message based on errno, but then this information has to be sent. This is done with sbus_reply_error which takes four arguments, two of them come from the aforementioned function but where can I find the other two? The ones that are missing are struct sbus_connection conn and DBusMessage reply_to. As far as I can see IFP doesn't manage this type of information.

Hi, you do not need to deal with sbus errors at all. It is sufficient to just return error from the d-bus method handler. I.e. in case of the aforementioned method ifp_users_find_by_cert_done receives this new error from cache_req_user_by_cert_recv and fails the tevent request with tevent_req_error. So the job here is already done.

• master
  • 16be48f - cache_req: propagate multiple entries error to the caller

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3751

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.