SSSD / sssd

#3957 sudo: runAsUser/Group does not work with domain_resolution_order
Closed: Fixed by jhrozek. Opened by pbrezina.

Closed: Fixed
Reopen Issue

Steps to reproduce:
1. Configure domain_resolution_order = ipa.domain:ad.domain
2. Configure sudo rule (sudoCommand=ALL, sudoHost=ALL, sudoUser=ALL, sudoRunAsUser=admin)
3. su admin
4. sudo -l will show that user can run all commands as admin
5. sudo ls will not work

If domain_resolution_order is set that one can login with a non-qualified name, however all outputs from nss responder are fully qualified. This cause trouble to sudo because it then expects sudoRunAsUser/Group attributes to be qualified as well (this is already patched for sudoUser).

sudo[123611] user admin@ipa.vm matches sudoers user admin: false @ userpw_matches() ./match.c:941
$ id admin
uid=1231200000(admin@ipa.vm) gid=1231200000(admins@ipa.vm) groups=1231200000(admins@ipa.vm)

We need to return either qualified or non qualified names here, based on configuration.

Metadata Update from @pbrezina:
- Issue assigned to pbrezina

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 2.2

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1671138

Issue linked to Bugzilla: Bug 1671138
  • master:
  • 0aa6571
  • d411feb
  • sssd-1-16:
  • 3a18e33
  • 5ad7f5e

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

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/4931

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.
Metadata
None
None
None
High
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.