[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.2 How Become sets up the environment

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.2.1 Environment variables created by Become

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] [ ? ]

1.2.2 Login styles

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.2.2.1 The `preserve' login style

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] [ ? ]

1.2.2.2 The `set-user' login style

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] [ ? ]

1.2.2.3 The `login' login style

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] [ ? ]

1.2.3 Tweaking individual environment variables

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:

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] [ ? ]

1.2.4 Variables removed from the environment

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.