[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are thorny problems with handling the user's environment. It seems that (the author's initial assessment notwithstanding) there is no single best way of handling environment variables. As a result, Become can do just about everything you might want it to. This gets slightly complicated. Don't worry: it's not as hard as all that.
1.2.1 Environment variables created by Become | Become adds some useful environment variables | |
1.2.2 Login styles | Choose how Become sets the environment | |
1.2.3 Tweaking individual environment variables | Altering individual environment variables | |
1.2.4 Variables removed from the environment | Some environment variables aren't passed on |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To help you (and, more importantly, your startup scripts) keep track of who you are, and who you were originally, Become adds some variables to the environment of any processes it starts.
BECOME_USER
The name of the target user (i.e., the user you are now). It might be useful to test this value in shell startup scripts, for example.
BECOME_HOME
The home directory of the target user. It can be handy to read startup and other configuration files from here.
BECOME_OLD_USER
The name of the user who invoked Become.
BECOME_OLD_HOME
The home directory of the `old' user.
BECOME_ORIGINAL_USER
This is intended to be the name you logged in with. If it's unset, Become
sets it to be the same as BECOME_OLD_USER
; otherwise it leaves it
unchanged.
BECOME_ORIGINAL_HOME
This is intended to be the home directory you logged in with. If it's unset,
Become sets it to be the same as BECOME_OLD_HOME
; otherwise, it leaves
it unchanged.
Don't even think about relying on these variables as a form of authentication. It won't work. They're provided only to help organise startup scripts.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Originally, Become always tried to preserve your environment. There's a rational explanation for this approach, which is given in the description of the `preserve' style below. Unfortunately, not everyone liked this approach. As a result, there's now a collection of different login styles.
Login styles are selected by giving command line arguments:
-e
--preserve
The original style: try to preserve the existing user's environment as much as possible.
-s
--set-user
Set some user-specific variables, like USER
and HOME
to reflect
the target user rather than the old user. All other variables are preserved.
-l
--login
Attempts to make the `become' process as much like a real login as possible. All variables not explicitly preserved are deleted, and a new environment is built, reflecting the target user.
The various styles, and the reasons behind them, are described below.
1.2.2.1 The `preserve' login style | Preserve the current environment | |
1.2.2.2 The `set-user' login style | Set user-specific variables (like su )
| |
1.2.2.3 The `login' login style | Clear the environment (like login )
|
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You've spent many hours (days? weeks, even?) customising and honing your startup files, learning how to use your shell, and tweaking your favourite text editor until it's just the way you like it. So there can be few things more annoying than logging into a shared account to find out that the shell's wrong, your editor startup files are ignored, and nothing works quite the way you'd like it to. Typically you can't change this without annoying the other users: the result is a horrible compromise which dissatisfies everyone equally.
The `preserve' style lets you take your standard environment with you when you become someone else. It tries hard not to modify any environment variables.
Become starts your standard shell. If you have an environment variable
SHELL
defined, than this is executed. Otherwise, the shell specified
in your entry in the password file is used. (You must have permission to
execute whatever shell is chosen as the target user, or you'll just be given
an error message.)
Most programs look at environment variables in preference to looking up
entries in the password database; e.g., they tend to use USER
or
LOGNAME
for the user name, and HOME
for your home directory.
As a result, most programs will continue to find their configuration files in
your home directory. Also, systems like RCS will use your real name, rather
than the name of the user that you have become.
To make best use of this login style, you may need to adjust your login
scripts to notice when BECOME_USER
is someone else, and read in
appropriate definitions. For example, a `bash' user might say something like
this in her `.bashrc':
if [ -n "$BECOME_HOME" ]; then . $BECOME_HOME/.bashrc |
Similarly, a C shell user (either `tcsh' or `csh') might say something like
if ($?BECOME_HOME) source ${BECOME_HOME}/.cshrc |
(Note that plain Bourne shell users have a slight problem, because the Bourne shell only reads configuration things on a login, not when a normal interactive shell is started.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The author sees the main use of Become as allowing a user to acquire the privileges associated with a shared account without all the problems which shared accounts usually cause. To the author's way of thinking, one of the main problems is that your environment gets replaced by something alien and wrong. People disagree with me over this point, and for this reason the `set-user' style exists.
The objective of `set-user' style is to behave similarly to the standard
su
command. Unless they've been preserved explicitly (see section Tweaking individual environment variables), `set-user' mode sets the following environment variables:
USER
LOGNAME
The name of the target user.
HOME
The home directory of the target user.
SHELL
The target user's default shell
The result of this is that the shell will read the target user's configuration files and present you with the environment set up there.
I can't think of this style as being anything other than a migration aid while users are getting used to the freedom offered by the `preserve' style.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `login' style causes Become to attempt to emulate a full login. Become will empty the environment of almost variables which aren't explicitly preserved (see section Tweaking individual environment variables). However, the following variables are retained:
It will set the following variables:
USER
LOGNAME
The name of the target user.
HOME
The home directory of the target user.
SHELL
The target user's default shell
MAIL
An educated guess at where the target user's mailbox is.
By default, it runs the target user's shell, informing it that this is a
login by setting the first character of argv[0]
to `-'.
Become makes no entries in the `utmp' and `wtmp' files.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Become's login styles provide a sort of course-grained control over the environment. Sometimes the control isn't fine enough. Become lets you tweak individual variables: you can set, delete, or preserve named variables from modification.
There are three different things you can do with environment variables:
var=value |
The variable is preserved from automatic deletion by the login-style rules.
var- |
var! |
Just to try and make this slightly more sensible, here's an example. Suppose
I want my XAUTHORITY
variable to be set when I become user `fred':
become XAUTHORITY=$HOME/.Xauthority fred |
should do the job nicely. Similarly, if I want to log in as `bob', but don't
want my EDITOR
variable to change:
become --login EDITOR! bob |
(Of course, in this example, I'm at the mercy of Bob's shell init files as to whether his choice of editor overrides mine.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some variables are removed from the environment which Become passes to a program for security reasons:
LD_*
SHLIB_PATH
LIBPATH
_RLD_*
These variables are used on various systems as a search path for shared libraries. Clearly, by manipulating these search paths, an attacker could replace a standard shared library with one of his own.
IFS
The shell input field separator. Modifying this variable radically alters
the way shells parse their inputs. (In particular, consider the case where
IFS
contains `/'.)
ENV
BASH_ENV
Used by some shells: it contains the name of a file to read on every shell invocation.
KRB_CONF
Contains the name of a Kerberos configuration file. By manipulating this variable, an attacker could persuade a program to believe the wrong authentication server.
Also note that the PATH
variable is modified: any items which aren't
absolute pathnames are removed from the path. This check may become stricter
in future, although getting the balance between security and convenience is
particularly hard here.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Mark Wooding on March, 14 2006 using texi2html 1.76.