ksh doesn't reed root's .profile

[sputnik]

Anyone has a clue? If i use "su - root", i have all aliases in /root/.profile working. If i use "su", /root/.profile doesn't seem to be read by ksh. What's the solution? Typing "su - root" every time is annoying.

[rocket357]

Originally Posted by sputnik

Anyone has a clue? If i use "su - root", i have all aliases in /root/.profile working. If i use "su", /root/.profile doesn't seem to be read by ksh. What's the solution? Typing "su - root" every time is annoying.

That's intended behavior. If you simply "su", you're keeping your environment while gaining elevated priv. If you "su -", you are using a login shell to read root's environment.

Read ksh's manpage (search for login shell and privileged shell).

[sputnik]

Just read it, but haven't found a solution. I've also noted when i use "su" i'm keeping my environment partly. E.g. exported variables like PKG_PATH or CVSROOT are preserved, but aliases ar not. I'm confused.

[sputnik]

And also variable PATH is not preserved (/usr/local/sbin particularly). Is this really intented behaviour? Some variables ar kept and some are not.

[jggimi]

You might consider a couple of additional man pages:

From su(1):

By default, the environment is unmodified with the exception of LOGNAME,
HOME, SHELL, and USER. HOME and SHELL are set to the target login's
default values. LOGNAME and USER are set to the target login, unless the
target login has a user ID of 0 and the -l flag was not specified, in
which case it is unmodified. The invoked shell is the target login's.
This is the traditional behavior of su.

and a command you may not have considered, sudo(8), which has significantly more capability than su. You can set the environment variables you want carried over, or not, by configuration file. And then, you can even override them, as described here for the -E operand:

The -E (preserve environment) option will override the
env_reset option in sudoers(5)). It is only available when
either the matching command has the SETENV tag or the
setenv option is set in sudoers(5).

Of course, you'll want to read sudoers(5) as well.

[rocket357]

Solution to what? You haven't been clear about what you *expect* to have happen, and how that differs from what you're observing.

I'm hazarding a guess here...a very quick and dirty workaround (if I'm understanding your complaint correctly) would be to alias su="su -", then source your alias file at the bottom of your .profile.

[sputnik]

That's correct, you've understood my complaint correctly enough. I've reread su(1) manpage and found bit more acceptable "solution" to alias su='su -m'. Thanks for answers!

[Oko]

Originally Posted by sputnik

That's correct, you've understood my complaint correctly enough. I've reread su(1) manpage and found bit more acceptable "solution" to alias su='su -m'. Thanks for answers!

Which posses security risk ...

[sputnik]

Originally Posted by Oko

Which posses security risk ...

How? I presume su -l could be a security risk, but not su -m... :/

[Oko]

Originally Posted by sputnik

How? I presume su -l could be a security risk, but not su -m... :/

You got it wrong. Reading .profile IS a security risk. Default behavior when you
log as su - and do NOT read .profile is NOT a security risk. Just think about it for a second.

[sputnik]

Originally Posted by Oko

You got it wrong. Reading .profile IS a security risk. Default behavior when you
log as su - and do NOT read .profile is NOT a security risk. Just think about it for a second.

But 'su -m' doesn't read target user's .profile, it leaves unmodified environment as says man su(1)

Leave the environment unmodified. The invoked shell is your login shell, and no directory changes are made.

Also csh would read root's .cshrc. Does that mean csh is not secure as root shell?

[mechanic]

I found that even with 'su -' some environment variables were read and some were not (as explained above) and the working directory changed to /root too. The aliases issue had to be overcome by putting those in a .kshrc file referred to by a $ENV variable defined in .profile. Running 'su' carries over the aliases defined in the user directory without changing working directory which I find useful.

[Oko]

Originally Posted by sputnik

Also csh would read root's .cshrc. Does that mean csh is not secure as root shell?

Roots .cshrc is OK. What you do not want is to read .cshrc from your regular user account. My understanding was that he wants exactly that. To read all the environment of the regular user. I will admit that would make work more convenient but on the multi user system is just plain dangerous.

[sputnik]

Originally Posted by Oko

on the multi user system is just plain dangerous.

Not convinced. "just plain dangerous" is not an argument.