Bug 878030

Summary:	su command's return value is wrong when pam_sss is enabled.
Product:	Red Hat Enterprise Linux 7	Reporter:	Najmuddin Chirammal <nc>
Component:	sssd	Assignee:	Jakub Hrozek <jhrozek>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Kaushik Banerjee <kbanerje>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	dpal, grajaiya, jgalipea, jhrozek, patdung100+redhat, pbrezina, piotr.zawadzki, steve.traylen, yjog
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	905340 (view as bug list)		Environment:
Last Closed:	2013-02-01 08:27:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	905340

Description Najmuddin Chirammal 2012-11-19 13:49:53 UTC

When a command is run via su from root, the exit status is always 0, even if the command fails.

For example : 

# service sssd status
sssd (pid  3009) is running...

# su - local_user -c "ls -8" ; echo $?
ls: invalid option -- '8'
Try `ls --help' for more information.
0

# service sssd stop
Stopping sssd:                                             [  OK  ]
# su - local_user -c "ls -8" ; echo $?
ls: invalid option -- '8'
Try `ls --help' for more information.
2

* User local_user is a local user (from /etc/passwd file)
* If we stop the sssd service(or remove pam_sss from pam 'session' section, then the command exit status is correct.

How reproducible:
Always
Version-Release number of selected component (if applicable): sssd-1.8.0-32.el6.x86_64


Steps to Reproduce:
1. Run, # su - local_user -c "ls -8" ; echo $? 
2. check the return value.

  
Actual results: su always returns 0

Expected results: su returns failure if the command fails.

Comment 1 Dmitri Pal 2012-11-19 15:26:40 UTC

Why this is an SSSD bug?
Does it behave correctly if pam_unix is used instead of pam_sss?

Comment 2 Jakub Hrozek 2012-11-19 15:46:44 UTC

We discussed the issue on IRC with Najmuddin. The problem is that the session stack of pam_sss doesn't check if the user it is processing is handled by the SSSD. We should check the existence of the user and return PAM_USER_UNKNOWN so that the pam stack carries on.

The simple workaround is to use pam_localuser.so

Comment 3 Jakub Hrozek 2012-11-26 11:12:32 UTC

Upstream ticket:
https://fedorahosted.org/sssd/ticket/1670

Comment 4 Jakub Hrozek 2012-12-11 11:28:42 UTC

*** Bug 886015 has been marked as a duplicate of this bug. ***

Comment 5 piotr.zawadzki 2012-12-11 12:05:58 UTC

(In reply to comment #4)
> *** Bug 886015 has been marked as a duplicate of this bug. ***

Can you send me a link how pam_localuser.so should be defined?

Comment 6 piotr.zawadzki 2012-12-11 12:17:35 UTC

I've checked the configuration and it looks that pam_localuser.so is defined:

---------------------

auth        required      pam_tally.so deny=5 onerr=fail file=/var/log/faillog no_magic_root
auth        required      pam_env.so
auth        sufficient    pam_unix.so try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet user ingroup La_KR_SRV_0007_AA
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so
#
account     required      pam_tally.so  deny=5 file=/var/log/faillog reset no_magic_root
account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so
#
password    required      pam_cracklib.so retry=3 minlen=8 dcredit=0 ucredit=0 lcredit=0 ocredit=0 type=
password    sufficient    pam_unix.so remember=7 use_authtok md5 shadow
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so
#
session     required      pam_mkhomedir.so umask=0022 skel=/etc/skel/
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     sufficient    pam_sss.so
session     required      pam_unix.so

Comment 7 piotr.zawadzki 2012-12-11 12:23:57 UTC

and last but not least - when is it going to be fixed?

Comment 8 Najmuddin Chirammal 2012-12-11 12:27:55 UTC

(In reply to comment #6)
> I've checked the configuration and it looks that pam_localuser.so is defined:

You should add a 'pam_localuser.so' entry under "session" section, prior to pam_sss.

for eg: 


session     required      pam_mkhomedir.so umask=0022 skel=/etc/skel/
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     sufficient    pam_localuser.so  ## <-Add
session     sufficient    pam_sss.so
session     required      pam_unix.so

Comment 9 Jakub Hrozek 2012-12-11 13:13:08 UTC

(In reply to comment #7)
> and last but not least - when is it going to be fixed?

Currently scheduled for upstream 1.10 release. Please work with your support representative if you need this bug to be fixed sooner.

Comment 11 Jakub Hrozek 2013-02-01 08:27:54 UTC

See https://bugzilla.redhat.com/show_bug.cgi?id=905340#c3

This problem was fixed in the 6.4 rebase to 1.9 as a side effect of improving PAM return codes.