When we use PUM/PAM on AIX servers I noticed (and also the users) variables defined on /etc/environment are not setup when access through PAM.

Since PAM uses their own SHELL, /usr/bin/pcks and mostly admins using the option: set –o remote for complete session control, we don't login really through the AIX server, we only invoke the commands using the privileged shell and PAM agent (installed on the server).
So, what means this?

Let me explain in a nutshell how is the AIX login process:

                   +---------+   +-----------------+    +-----------+
             +---> | valid   +-> |environment setup+--> | /etc/motd |
             |     +---------+   +-----------------+    +------+----+
+-------+    +---+--+                                              |
| getty +--> |login |                                         +----v----+
+-------+    +---+--+                                         |  shell  |
             |     +---------+                                +----+----+
             +---> | invalid |                                 |     
                   +---------+                             +---v---+ 
                     +--v--+                               | w00t! | 
                     | bye |                               +-------+ 
  • getty is launched by init and reads: /etc/security/login.cfg.
  • login read the username and check: /etc/passwd and /etc/security/passwd and validate is the user needs password if is true: "password:" prompt show up.
  • Invalid usernames are logged in /etc/security/failedlogin, invalid password are logged in /etc/security/lastlog, on both cases: bye.
  • For valid logins, first /etc/security/login.cfg is cheked for maxlogins value, if this value is exceeded, the login is denied and then bye.
  • If all is ok, then AIX read and set variables and configurations from: /etc/environment /etc/security/environ /etc/security/limits /etc/security/user.
  • After this, displays Message of the Day defined on /etc/motd and some more login info.
  • At the end, AIX run the shell defined in /etc/passwd and this read /etc/environment and execute /etc/profile $HOME/.profile $HOME/.kshrc (last one for Korn shell only).
  • w00t!

Very simple right?
At what point PAM comes here with the configuration described?

Users "login" in to the server runs /usr/bin/pcks (also defined in /etc/passwd) as client and ask all commands against PAM's Command Control Manager
At this point comes the rules and others PAM's configurations, but, never read /etc/environment

Many vendors put their variables there for DBs, Web services, App users, etc. this means is different in each AIX server, and this is more complicated if we are talking about almost 1,000 servers... to fix this I made a very simple dirty-hack.

Fortunately /usr/bin/pcks as Korn shell based, run $HOME/.profile and with a simple snippet we can parse and setup variables in /etc/environment:

for v in \$(awk '!/^ *#/ && NF' /etc/environment | grep -v ^alias);do export \$v;done  

With this, in every "login" through PAM, read the variables, ignore the aliases and export the variables.
But, insert this snippet in a server with many users with different $HOME and different $SHELL, multiplied by hundreds of servers... is very easy too:

# wvera@suse.com

for l in `grep -E '(/usr/bin/ksh|/usr/bin/pcksh)' /etc/passwd | grep -v ^root | awk -F":" {'print $1":"$6'}`  
        VUSER=`echo $l | awk -F":" {'print $1'}`
        VHOME=`echo $l | awk -F":" {'print $2'}`
        cp $VHOME/.profile $VHOME/.profile.BKENV
        cat >> $VHOME/.profile << EOF
# Read /etc/environment parse it and set the variables for AIX and PUM 2.4 / PAM 3
for v in \$(awk '!/^ *#/ && NF' /etc/environment | grep -v ^alias);do export \$v;done  
# End
        chown $VUSER $VHOME/.profile

This script looking for a "valid" PAM Shells, and their users associated, see the $HOME, backup $HOME/.profile, insert the snippet and change the permission of the file to user can execute it.


Billy Vera © 2017. All Rights Reserved.

The opinions expressed in this blog are purely my own and are not in any way endorsed by my employer.

Proudly published with Ghost using Ghostium Theme