Bug 878030 - su command's return value is wrong when pam_sss is enabled.
su command's return value is wrong when pam_sss is enabled.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
7.0
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jakub Hrozek
Kaushik Banerjee
:
: 886015 (view as bug list)
Depends On:
Blocks: 905340
  Show dependency treegraph
 
Reported: 2012-11-19 08:49 EST by Najmuddin Chirammal
Modified: 2014-06-18 03:08 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 905340 (view as bug list)
Environment:
Last Closed: 2013-02-01 03:27:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Najmuddin Chirammal 2012-11-19 08:49:53 EST
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 10:26:40 EST
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 10:46:44 EST
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 06:12:32 EST
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1670
Comment 4 Jakub Hrozek 2012-12-11 06:28:42 EST
*** Bug 886015 has been marked as a duplicate of this bug. ***
Comment 5 piotr.zawadzki 2012-12-11 07:05:58 EST
(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 07:17:35 EST
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 07:23:57 EST
and last but not least - when is it going to be fixed?
Comment 8 Najmuddin Chirammal 2012-12-11 07:27:55 EST
(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 08:13:08 EST
(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 03:27:54 EST
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.

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