Can't get user $HOME over su on Solaris and AIX

Question

I'm trying to get user $HOME variable over su.

Solaris

# su oracle
$ echo $HOME
/root

AIX

# su oracle
$ echo $HOME
/

Linux

# su oracle
$ echo $HOME
/home/oracle

Can someone explain why on Solaris and AIX when I try to get $HOME variable it gets the root's $HOME directory?

UPDATE

Using login with with - or -l works, but I can't use su - on my script. Any thoughts on how to overcome this?

I was trying to not use a solution like the above but I'm getting out of options

cat /etc/passwd | grep oracle | cut -d: -f 6

or as Thomas suggested:

cat /etc/passwd | awk -F: '$1 ~ /^'oracle'$/ {print $6;}'

Is the oracle user homedir exists on both systems ? If yes try su - oracle — MAQ, Mar 06 '16 at 00:10
@KWubbufetowicz, yes they exists. And I've tried with -l. It doesn't work. — Bernardo Vale, Mar 06 '16 at 00:18
The double-quotes in the su - commands would expand in the current shell (not after su). Using single-quotes would help. — Thomas Dickey, Mar 06 '16 at 00:26
You are right, just forget about this test. It works, but unfortunetly I can't use su - on the main script because it's ansible code — Bernardo Vale, Mar 06 '16 at 00:29
Hi Thomas, I've updated the question with your suggestion. Could you elaborate why the approach it's better? Also, does you know if the position of home directory inside passwd it's the same on all unix distributions? — Bernardo Vale, Mar 06 '16 at 00:51
On, Solaris, I'd use getent passwd oracle to find the right entry in the passwd database, regardless of whether it's in a local file, NIS, or LDAP. — alanc, Mar 06 '16 at 15:55
Nice @alanc I wish I could use this "getent" but this code needs to work on all distributions. — Bernardo Vale, Mar 07 '16 at 12:11

Thomas Dickey · Accepted Answer · 2016-03-06T00:55:39.400

Actually (quick check) su (from a non-privileged user to another non-privileged user) on Solaris does not modify $HOME at all. Perhaps you were root when issuing the su command.

The Solaris manual page is silent on the matter, but it is a known issue, quoting from a newsgroup comment:

nails September 16, 2008 at 18:16:45

    jefro:

    Sorry I must disagree wtih you. At least in Solaris su <user id>
    doesn't change the user environment - including environmental
    variables. To change the environment, you must execute
        su - <user id>

    According to the su MAN page:

    If the first argument to su is a dash (-), the environment will
    be changed to what would be expected if the user actually logged
    in as the specified user.

However, the manual page says things about several variables, but not HOME:

   o  In addition to what is already propagated, the LC*  and
      LANG  environment  variables  from the specified user's
      environment are also propagated.

   o  Propagate TZ from the user's environment. If TZ is  not
      found  in  the user's environment, su uses the TZ value
      from    the     TIMEZONE     parameter     found     in
      /etc/default/login.

   o  Set MAIL to /var/mail/new_user.


 If the first argument to su is a dash (-),  the  environment
 will  be changed to what would be expected if the user actu-
 ally  logged  in  as  the  specified  user.  Otherwise,  the
 environment  is  passed  along, with the exception of $PATH,
 which is controlled by PATH and SUPATH in /etc/default/su.

That last sentence can be construed to say that the current user's HOME variable is passed through without change (unless you use the "su -" form, of course).

Other systems:

The AIX manual page is less helpful, but since the feature is very old in both, the behavior may be based on the same source code.
HPUX manual page is also not helpful, saying that "The previously defined HOME and ENV environment variables are removed."

Because su is not giving you the information you need, a different approach would help. If your accounts all are local accounts (no LDAP), you can always search /etc/passwd, e.g.,

THATHOME=$( awk -F: '$1 ~ /^'$THATUSER'$/ {print $6;}' </etc/passwd )

Notes:

the format of /etc/passwd is the same on all Unix-like systems.
using awk to split up the field into fields avoids the problem with a grep picking up the wrong line (or lines), e.g., if you had an oracleadmin account.
If you had LDAP, you might have the utility getent which would allow referring to non-local users.

Thomas, thanks for your help. I've also tried with su -, check my last update. — Bernardo Vale, Mar 06 '16 at 00:23

score 1 · Answer 2 · answered Mar 06 '16 at 14:14

This is really simple, though a common source of misunderstanding. So common it has a Wikipedia entry:

Usage

When run from the command line, su asks for the target user's password, and if authenticated, grants the operator access to that account and the files and directories that account is permitted to access.
john@localhost:~$ su jane
Password:
jane@localhost:/home/john$ exit
logout
john@localhost:~$
When used with a hyphen (su -) it can be used to start a login shell. In this mode users can assume the user environment of the target user:
john@localhost:~$ su - jane
Password:
jane@localhost:~$

To run a command under a user's environment:

su - user -c "command [args]"

Hello Andrew, thanks for your contribution, unfortunately I can't use "su -". The code who does privilege escalation it's ansible.com, and it use su without login (" -"). — Bernardo Vale, Mar 07 '16 at 12:15
@BernardoVale - So simply write a wrapper script that you start as root with su. Inside the script run su - username -c "command [args]" — Andrew Henle, Mar 07 '16 at 13:04

Can't get user $HOME over su on Solaris and AIX

UPDATE

2 Answers2

Linked