RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1607313 - When sssd is running as non-root user, the sudo pipe is created as sssd:sssd but then the private pipe ownership fails
Summary: When sssd is running as non-root user, the sudo pipe is created as sssd:sssd ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: sssd-qe
Lucie Vařáková
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-23 09:25 UTC by Jakub Hrozek
Modified: 2020-05-02 18:58 UTC (History)
11 users (show)

Fixed In Version: sssd-1.16.2-8.el7
Doc Type: Known Issue
Doc Text:
Cause: To address a secutiry issue, the UNIX pipe that sudo uses to communicate with the SSSD had much tighter permissions than before. In the case of SSSD running as a non-root user (by using user=sssd in the [sssd] section of sssd.conf), there was an additional permissions check in sssd that never succeeded for the sudo pipe. Consequence: sudo was not usable with sssd running in the non-root mode. Workaround (if any): either remove the sss module from the sudoers line in nsswitch.conf or disable the sudo responder. Both workarounds would disable fetching sudo rules through sssd. Alternarnatively, run sssd as root. Result: What am I supposed to write here? We temporarily broke sssd sudo support when running as a non-root user. It's fixed now.
Clone Of:
Environment:
Last Closed: 2018-10-30 10:42:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4784 0 None closed When sssd is running as non-root user, the sudo pipe is created as sssd:sssd but then the private pipe ownership fails 2020-11-17 13:48:26 UTC
Red Hat Product Errata RHSA-2018:3158 0 None None None 2018-10-30 10:43:33 UTC

Description Jakub Hrozek 2018-07-23 09:25:34 UTC
This bug is created as a clone of upstream ticket:
https://pagure.io/SSSD/sssd/issue/3778

Since commit ed90a20a0f0e936eb00d268080716c0384ffb01d, the sudo pipe is a private one. This means that the responder asserts that the owner of the pipe is root:root. But this is not the case when sssd is running as unprivileged user, then the pipe is created as sssd:sssd and the check never succeeds.

Comment 4 Jakub Hrozek 2018-07-25 20:24:28 UTC
* master:
 * 21ea8204a0bd8ea4451f420713e909d3cfee34ef                                                                                                                                                                                                    
 * 4900b8e59bdbb89fbc1c9718969aabe26f3db34a

Comment 7 shridhar 2018-08-16 14:06:11 UTC
Issue was reproduced using rpm  =  sssd-common-1.16.2-7.el7.x86_64
Initial configuration (with root user)
~]# cat /etc/sssd/sssd.conf 
[sssd]
config_file_version = 2
domains             = LDAP
services            = nss, pam, sudo
debug_level         = 0xFFFF

[nss]
filter_groups       = root
filter_users        = root

[pam]

[sudo]
debug_level         = 0xFFFF
sudo_timed          = true

[domain/LDAP]
id_provider         = ldap
auth_provider       = ldap
sudo_provider       = ldap
debug_level         = 0xFFFF
ldap_uri            = ldaps://vm-idm-023.lab.eng.pnq.redhat.com
ldap_tls_cacert     = /etc/openldap/certs/cacert.asc
ldap_search_base    = dc=example,dc=com

ldap_sudo_smart_refresh_interval = 10


[root@vm-idm-018 ~]# id testuser
uid=1000014(testuser) gid=1000014 groups=1000014
[root@vm-idm-018 ~]# sudo -l testuser -U
sudo: testuser: command not found
[root@vm-idm-018 ~]# sudo -l -U testuser
Matching Defaults entries for testuser on vm-idm-018:
    !authenticate

User testuser may run the following commands on vm-idm-018:
    (root) NOPASSWD: /usr/bin/id

##### editing sssd.conf to run the sssd as non root user
[root@vm-idm-018 ~]# vi /etc/sssd/sssd.conf 
[root@vm-idm-018 ~]# cat /etc/sssd/sssd.conf 
[sssd]
config_file_version = 2
domains             = LDAP
services            = nss, pam, sudo
debug_level         = 0xFFFF
user		    = sssd

[nss]
filter_groups       = root
filter_users        = root

[pam]

[sudo]
debug_level         = 0xFFFF
sudo_timed          = true

[domain/LDAP]
id_provider         = ldap
auth_provider       = ldap
sudo_provider       = ldap
debug_level         = 0xFFFF
ldap_uri            = ldaps://vm-idm-023.lab.eng.pnq.redhat.com
ldap_tls_cacert     = /etc/openldap/certs/cacert.asc
ldap_search_base    = dc=example,dc=com

ldap_sudo_smart_refresh_interval = 10


###

#$ service sssd stop; rm -rf /var/lib/sss/db/* ; service sssd start
 ~]# ps auxf |head -n1; ps auxf|tail -n4
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
sssd      3852  0.3  0.2 298292  8540 ?        S    19:21   0:00  \_ /usr/libexec/sssd/sssd_be --domain LDAP --uid 997 --gid 993 --logger=files
sssd      3853  0.1  0.7 264648 28752 ?        S    19:21   0:00  \_ /usr/libexec/sssd/sssd_nss --uid 997 --gid 993 --logger=files
sssd      3854  0.0  0.1 244316  4108 ?        S    19:21   0:00  \_ /usr/libexec/sssd/sssd_pam --uid 997 --gid 993 --logger=files
sssd      3855  0.0  0.1 237756  4020 ?        S    19:21   0:00  \_ /usr/libexec/sssd/sssd_sudo --uid 997 --gid 993 --logger=files
[root@vm-idm-018 ~]# sudo -l -U testuser
^C


^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C












^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^CYou have mail in /var/spool/mail/root


####### Above shows that terminal is in hung state.




From other terminal updated the sssd to updated version.


 ~]# yum update sssd
Resolving Dependencies
--> Running transaction check
---> Package sssd.x86_64 0:1.16.2-7.el7 will be updated
---> Package sssd.x86_64 0:1.16.2-12.el7 will be an update
--> Processing Dependency: python-sssdconfig = 1.16.2-12.el7 for package: sssd-1.16.2-12.el7.x86_64
--> Processing Dependency: sssd-ad = 1.16.2-12.el7 for package: sssd-1.16.2-12.el7.x86_64
--> Processing Dependency: sssd-common = 1.16.2-12.el7 for package: sssd-1.16.2-12.el7.x86_64
.
[...]
Updated:
  sssd.x86_64 0:1.16.2-12.el7                                                                                                                     

Dependency Updated:
  libipa_hbac.x86_64 0:1.16.2-12.el7               libsss_autofs.x86_64 0:1.16.2-12.el7           libsss_idmap.x86_64 0:1.16.2-12.el7            
  libsss_simpleifp.x86_64 0:1.16.2-12.el7          libsss_sudo.x86_64 0:1.16.2-12.el7             python-sss.x86_64 0:1.16.2-12.el7              
  python-sssdconfig.noarch 0:1.16.2-12.el7         sssd-ad.x86_64 0:1.16.2-12.el7                 sssd-client.x86_64 0:1.16.2-12.el7             
  sssd-common.x86_64 0:1.16.2-12.el7               sssd-common-pac.x86_64 0:1.16.2-12.el7         sssd-dbus.x86_64 0:1.16.2-12.el7               
  sssd-ipa.x86_64 0:1.16.2-12.el7                  sssd-krb5.x86_64 0:1.16.2-12.el7               sssd-krb5-common.x86_64 0:1.16.2-12.el7        
  sssd-ldap.x86_64 0:1.16.2-12.el7                 sssd-proxy.x86_64 0:1.16.2-12.el7              sssd-tools.x86_64 0:1.16.2-12.el7              



[root@vm-idm-018 ~]# cat /etc/sssd/sssd.conf 
[sssd]
config_file_version = 2
domains             = LDAP
services            = nss, pam, sudo
debug_level         = 0xFFFF
user		    = sssd

[nss]
filter_groups       = root
filter_users        = root

[pam]

[sudo]
debug_level         = 0xFFFF
sudo_timed          = true

[domain/LDAP]
id_provider         = ldap
auth_provider       = ldap
sudo_provider       = ldap
debug_level         = 0xFFFF
ldap_uri            = ldaps://vm-idm-023.lab.eng.pnq.redhat.com
ldap_tls_cacert     = /etc/openldap/certs/cacert.asc
ldap_search_base    = dc=example,dc=com

idm-018 ~]# rpm -q sssd
sssd-1.16.2-12.el7.x86_64]
 ~]# service sssd stop; rm -rf /var/lib/sss/db/* ; service sssd start
Redirecting to /bin/systemctl stop sssd.service
Redirecting to /bin/systemctl start sssd.service
[root@vm-idm-018 ~]# sudo -l -U testuser
Matching Defaults entries for testuser on vm-idm-018:
    !authenticate

User testuser may run the following commands on vm-idm-018:
    (root) NOPASSWD: /usr/bin/id

Comment 8 shridhar 2018-08-16 14:07:36 UTC
In addition to comment #7. now the sudo pipe permissions are 
[root@vm-idm-018 ~]# ll /var/lib/sss/pipes/sudo 
srw-------. 1 sssd root 0 Aug 16 19:34 /var/lib/sss/pipes/sudo

Comment 11 errata-xmlrpc 2018-10-30 10:42:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3158


Note You need to log in before you can comment on or make changes to this bug.