#2710 Propagate error about multiple entries found from cache_req to responder
Closed: Fixed a year ago by pbrezina. Opened 5 years ago by jhrozek.

When looking up a user by certificate, it is possible for two user entries to exist. In that case, we should return a special error code so that the cache_req user (IFP in this case) can display a user-friendly error message.


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)

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD Future releases (no date set yet)

3 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: easyfix

3 years ago

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

Metadata Update from @sbose:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

a year ago

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.

Metadata Update from @pbrezina:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

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

Metadata Update from @pbrezina:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

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.

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #4110 Closed a year ago