Bug 1702712

Summary: pam_env bypassed for root user when using su
Product: Red Hat Enterprise Linux 8 Reporter: Chris Cheney <ccheney>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Radka Brychtova <rskvaril>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: tmraz
Target Milestone: rc   
Target Release: 8.1   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: util-linux-2.32.1-10.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2000137 (view as bug list) Environment:
Last Closed: 2019-11-05 22:26:57 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: 2000137    

Description Chris Cheney 2019-04-24 14:27:12 UTC
Description of problem:

Due to being one of the few pam stacks that uses pam_rootok.so, /etc/pam.d/su bypasses pam_env when run as root. pam_env is in system-auth as the first entry which is not reached.

This causes variables set in /etc/environment to not be set.

A potential work around would be to either remove 'auth sufficient pam_rootok.so' or to add 'session required pam_env.so'


/etc/pam.d/su

   #%PAM-1.0
   auth		sufficient	pam_rootok.so
   # Uncomment the following line to implicitly trust users in the "wheel" group.
   #auth		sufficient	pam_wheel.so trust use_uid
   # Uncomment the following line to require a user to be in the "wheel" group.
   #auth		required	pam_wheel.so use_uid
   auth		substack	system-auth
   auth		include		postlogin
   account		sufficient	pam_succeed_if.so uid = 0 use_uid quiet
   account		include		system-auth
   password	include		system-auth
   session		include		system-auth
   session		include		postlogin
   session		optional	pam_xauth.so

/etc/pam.d/system-auth

   #%PAM-1.0
   # This file is auto-generated.
   # User changes will be destroyed the next time authconfig is run.
   auth        required      pam_env.so
   auth        sufficient    pam_fprintd.so
   auth        sufficient    pam_unix.so nullok try_first_pass
   auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
   auth        required      pam_deny.so

   account     required      pam_unix.so
   account     sufficient    pam_localuser.so
   account     sufficient    pam_succeed_if.so uid < 1000 quiet
   account     required      pam_permit.so

   password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
   password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
   password    required      pam_deny.so

   session     optional      pam_keyinit.so revoke
   session     required      pam_limits.so
   -session     optional      pam_systemd.so
   session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
   session     required      pam_unix.so


Version-Release number of selected component (if applicable):

  util-linux-2.23.2-59.el7_6.1.x86_64


How reproducible:

  Every time as root


Steps to Reproduce:

  1. Set a variable in /etc/environment
  2. su as root user
  3. note the variables are not set

Actual results:

  /etc/environment variables are not set since pam_env is never reached.


Expected results:

  /etc/environment variables should be set.

Comment 2 Karel Zak 2019-04-26 10:14:45 UTC
I have doubts that RHEL-7 update is the right place for the change. You can solve the problem locally for example by "session required pam_env.so"

For RHEL it will be better do the change in RHEL-8.1 and Fedora. CC: Tomas (PAM maintainer)

The first possibility is to add pam_env to the session, or another way is to add pam_env to auth before pam_rootok. It seems safe to call
pam_env more than once and more easy than try to be smart with pam_succeed_if.so :-)

Comment 3 Karel Zak 2019-04-26 10:17:26 UTC
Moving to RHEL-8.1.

Comment 10 errata-xmlrpc 2019-11-05 22:26:57 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/RHBA-2019:3603