Bug 1607313

Summary:	When sssd is running as non-root user, the sudo pipe is created as sssd:sssd but then the private pipe ownership fails
Product:	Red Hat Enterprise Linux 7	Reporter:	Jakub Hrozek <jhrozek>
Component:	sssd	Assignee:	Jakub Hrozek <jhrozek>
Status:	CLOSED ERRATA	QA Contact:	sssd-qe <sssd-qe>
Severity:	unspecified	Docs Contact:	Lucie Vařáková <lmanasko>
Priority:	unspecified
Version:	7.3	CC:	fhanzelk, grajaiya, jhrozek, lmanasko, lslebodn, mkosek, mzidek, pbrezina, sgadekar, sgoveas, tscherf
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-30 10:42:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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