su and SHELL environment variable

[Stefan Hirsch_2]

Hi,

I observe a difference between HP-UX 11.00 and
11.11 with the settings of the SHELL environment
variable when doing a su - user.

Basically on 11.00 SHELL is set to the login
shell of the new user while on 11.11 the value
seems to be always /sbin/sh. The 11.00 behaviour is the one I would expect according
to the man pages of su and login.

To illustrate:

# uname -r
B.11.00
# useradd -s /bin/csh testusr
# printenv SHELL
/sbin/sh
# su - testusr -c 'printenv SHELL'
(c)Copyright 1983-1997 Hewlett-Packard Co.,

/bin/csh

# uname -r
B.11.11
# useradd -s /bin/csh testusr
# printenv SHELL
/sbin/sh
# su - testusr -c 'printenv SHELL' 2>/dev/null
(c)Copyright 1983-2000 Hewlett-Packard Co.,

/sbin/sh

Has anyone a idea why this happens? This is
quite annoying for csh users since the
usual construct of "eval `tset -s -Q`"
in .login files will not work any longer.

[Jose Mosquera]

Hi,

Are you shure that "csh" shell is placed into /bin directory in both systems?

Pls check this in both systems with:
#whence csh

The try again using the dsiplayed path. In my case "csh" shell is placed into /usr/bin/ in both systems.

Rgds.

[Jeff Schussele]

Hi Stefan,

What is contained in /etc/shells on each of these systems?
Is it possible that /usr/bin/csh is *not* in the file on the 11.11 system?
If it exists then the getusershell() sys call leaves the file open & will step through the entries on subsequent calls.
man 3c getusershell
for details.

HTH,
Jeff

[Stefan Hirsch_2]

Hi,

here is the content of /etc/shells:

11.11
# grep -v \# /etc/shells

/sbin/sh
/usr/bin/csh
/usr/bin/sh
/usr/bin/rsh
/usr/bin/ksh
/usr/bin/rksh
/usr/bin/keysh
/bin/csh
/bin/sh
/bin/ksh
/usr/bin/false

/bin/ftp_only

11.0
# grep -v \# /etc/shells
/sbin/sh
/sbin/sh
/usr/bin/sh
/usr/bin/rsh
/usr/bin/ksh
/bin/csh
/usr/local/bin/tcsh
/usr/bin/tcsh

/bin/csh is present on both systems.

/etc/csh.login is identical except for some
revision information.

Thanks and br
Stefan

[Carsten Krege]

I'm not 100% sure, but after checking the su(1) and environ(5) manual page, I'd say this behaviour is a bug.

When you use login(1) the SHELL variable is set correctly.

I recommend to open a call with HP to address this.

Carsten

[Robert-Jan Goossens]

could you give us a
# ll /bin/csh
on both systems ?

Regards,
Robert-Jan

[Stefan Hirsch_2]

Hi,

here is the ls -l output:

# uname -r
B.11.00
# ls -l /bin/csh
-r-xr-xr-x 1 bin bin 163840 Jan 24 2002 /bin/csh

# uname -r
B.11.11
# ls -l /bin/csh
-r-xr-xr-x 1 bin bin 155648 Sep 20 2002 /bin/csh

[Bill Hassell]

It's important to note that there is no such directory as /bin. It was removed many years ago when HP-UX adopted the V.4 filesystem layout. However, so many users and sysadmins had code that referred to /bin, a 'transition' link was created for /bin. This is what /bin looks like:

ll /bin
lr-xr-xr-t 1 root sys 8 Nov 5 2003 /bin@ -> /usr/bin

Same for /lib. Try creating the user with /usr/bin/csh. And while Linux is still languishing in the past with the older filesystem layout, it's worth using the new pathnames whenever possible. Transition links are the default right now, but HP may make these optional in a furture release.

[Stefan Hirsch_2]

Hi *,

as it turned out the problem is not related
to a difference between 11.0 and 11.11. I
tested it on another 11.11 machine and the
behaviour was ok. Seems to be a missing patch
on the machine I tested first. Since this
environment is no longer available to me
I cannot investigate it any further.

Thanks for all the replies.

Stefan

[Stefan Hirsch_2]

Hi again,

I'm back with this old issue. It seems that
I can now reproduce the problem that the
SHELL environment variable is not set
during a su - .

# uname -r
B.11.11
# useradd -s /usr/bin/csh tstusr1
# printenv SHELL
/sbin/sh
# su - tstusr1 -c 'printenv SHELL'
(c)Copyright 1983-2000 Hewlett-Packard Co.,

/sbin/sh

But this happens only when I'm logged in via
ssh. When logged in via rlogin on the same
machine the output of the printenv command
is the expected
/usr/bin/csh

The environment of both shells is almost identical. The differences are:
2a3
> SSH2_SFTP_LOG_FACILITY=-1
7a9,10
> USER=root
> DISPLAY=10.80.5.181:13.0
8a12
> SSH2_CLIENT=10.80.5.240 57514 10.80.5.181 22
i.e. the ssh shell has some more environment variables set.

Thanks for hints.

[Stefan Hirsch_2]

Hi *,

just for the record. The problem occured only
when logged in via ssh from Tectia, version
4.1.*. It does not appear with newer ssh versions either from Tectia or HP provided ssh versions. However, the problem is a bug in su. I've got a patched su version from HP support but there is no official patch.

BR
Stefan Hirsch