[become] / manual / become.texi

\input texinfo @c -*-texinfo-*-
@c
@c $Id: become.texi,v 1.7 2003/11/29 23:39:16 mdw Exp $
@c
@c Documentation for `become'
@c
@c (c) 1998 EBI
@c

@c ----- Revision history ---------------------------------------------------
@c
@c $Log: become.texi,v $
@c Revision 1.7  2003/11/29 23:39:16  mdw
@c Debianization.
@c
@c Revision 1.6  2003/10/26 11:57:46  mdw
@c Fix key reloading core dumps.  Change advice on keys.
@c
@c Revision 1.5  2003/10/12 00:14:49  mdw
@c Major overhaul.  Now uses DSA signatures rather than the bogus symmetric
@c encrypt-and-hope thing.  Integrated with mLib and Catacomb.
@c
@c Revision 1.4  1998/04/23 13:16:14  mdw
@c Include `texinice' to produce decent printed output.  Add documentation
@c for new `bcquery' program.  Various fixes, including spelling mistakes,
@c and some factual inaccuracies.
@c
@c Revision 1.3  1998/01/20 14:37:43  mdw
@c Fix typo.  Short form of `--preserve' should be `-e', not `-p'.
@c
@c Revision 1.2  1998/01/12 16:41:31  mdw
@c Tidying for new release versions.  Fix copyright date.
@c
@c Revision 1.1  1997/09/18 11:16:34  mdw
@c Brand new Texinfo manual, with wider scope than the original LaTeX one.
@c

@c ----- Standard boilerplate -----------------------------------------------

@c %**start of header
@setfilename become.info
@settitle Become
@setchapternewpage odd
@footnotestyle end
@paragraphindent 0
@iftex
@input texinice.tex
@afourpaper
@c @parindent=0pt
@end iftex
@c %**end of header

@dircategory Administration tools
@direntry
* Become: (become).        Shared account administration tool
@end direntry

@c ----- Useful macros ------------------------------------------------------

@set version 1.4

@c ----- Copyright matters --------------------------------------------------

@c --- The `Info' version ---

@ifinfo

This file documents Become version @value{version}.

Copyright (c) 1998 European Bioinformatics Institute.

Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

@ignore
Permission is granted to process this file through TeX and print the
results, provided the printed document carries a copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).

@end ignore
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
sections entitled `Copying' and `GNU General Public License' are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation
approved by the European Bioinformatics Institute.

@end ifinfo

@c --- Printed title page ---

@titlepage

@title The Become program
@subtitle Become version @value{version}
@author Mark Wooding @email{mdw@@ebi.ac.uk}
@page

@vskip 0pt plus 1filll

Copyright @copyright{} 1998 European Bioinformatics Institute.

Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
sections entitled `Copying' and `GNU General Public License' are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation
approved by the European Bioinformatics Institute.

@end titlepage


@c --------------------------------------------------------------------------
@ifinfo
@node Top, Copying, (dir), (dir)
@top Become


Become is a system for managing shared accounts.  It allows users to
`become' other users in order to do useful work.  It can be managed on a
central server (or a small number of central servers), or it can run
standalone.

This file documents Become version @value{version}.

@end ifinfo

@menu
* Copying::                     Your rights to distribute and modify
* Introduction::                A brief introduction to Become
* Becoming someone else::       How to become somebody else
* Administering Become::        How to maintain Become
* Invoking Become::             Reference to Become's command line options

@detailmenu
 --- The Detailed Node Listing ---

Becoming someone else

* Terminology::                 Some important terms defined
* Environment::                 Login styles and environment variables
* Group permissions::           How Become handles group permissions
* X authority::                 Problems with X authority files
* Running commands::            Running commands other than a shell

How Become sets up the environment

* New environment variables::   Become adds some useful environment variables
* Login styles::                Choose how Become sets the environment
* Tweaking the environment::    Altering individual environment variables
* Removed variables::           Some environment variables aren't passed on

Login styles

* The preserve style::          Preserve the current environment
* The set-user style::          Set user-specific variables (like @code{su})
* The login style::             Clear the environment (like @code{login})

How Become handles groups

* Primary group selection::     Setting the new primary group
* Subsidiary groups::           Setting subsidiary group memberships

Considerations for X authority

* The user-group method::       A fairly secure way of handling X authority
* Using xauth::                 A less secure method, which might be easier

Become administration

* Configuration files::         Overview of Become's configuration files
* Standalone or networked::     The two main types of Become installations
* The configuration file::      How to define who's allowed to do what
* Networked configuration::     Considerations for networked installations

The configuration file

* Requests and rules::          How the configuration file works
* Basic syntax::                Quick overview of Become's syntax
* Classes::                     Defining classes of things
* Predefined classes::          Become predefines some (maybe) useful classes
* Allow statements::            Allow users to become other users
* Other statements::            Some other useful statements
* Example configuration file::  An example, showing a few features.
* Checking and querying::       Checking and querying configuration files
* Complete grammar::            Complete grammar for Become config files

Checking and querying the configuration file

* Verifying config files::      Checking a configuration file is correct
* Querying config files::       Asking questions about privileges
* Output formats::              Different ways of formatting output
* Restricting output::          Being selective about what gets output
* bcquery reference::           Complete command line reference

Networked configuration

* Choosing servers::            Which servers Become tries to talk to
* Setting up keys::             How to generate keys for Become
* Issuing a new key::           How to issue new keys without disruption

Invoking Become

* Becoming another user::       Options for becoming another user
* Starting Become daemons::     Options for starting Become daemons
* Debugging options::           Options to use when Become goes wrong

@end detailmenu
@end menu

@c --------------------------------------------------------------------------
@node Copying, Introduction, Top, Top
@unnumbered The GNU General Public License

@include gpl.texi


@c --------------------------------------------------------------------------
@node Introduction, Becoming someone else, Copying, Top
@unnumbered Introduction


It's often useful to be able to share accounts between a number of
users.  For example, a group maintaining an externally visible service
need to be able to start and kill the server process.  Giving such a
shared account a password is a fairly bad plan: such passwords tend not
to get changed very often, and they have a habit of spreading beyond the
group of legitimate users.

The Become program presented here offers a solution to the problems of
shared accounts.  It allows the system administrator to define which
users are allowed access to which accounts, on which hosts, and to
execute which commands.  Such shared accounts can then, in general, have
their passwords removed.

This coincidentally has another advantage: when `becoming' to a shared
account, a user can retain her@footnote{Or his.  I'll choose one or the
other fairly randomly throughout this manual.} own environment, which
she's carefully crafted and honed over the years, rather then being
presented with some lowest-common-denominator setup which probably
doesn't even use the right shell.

The configuration file for Become can either be distributed to all the
various hosts in a network or a few carefully set up and secure servers
(@pxref{Standalone or networked}).


@c --------------------------------------------------------------------------
@node Becoming someone else, Administering Become, Introduction, Top
@chapter Becoming someone else


The simplest way to become someone else is to say

@example
become @var{user}
@end example

@noindent
Become will check to see whether you're allowed to become @var{user}.  If you
are, it starts a shell process with the user-id set to @var{user}.  Any
commands you type are executed with the privileges of @var{user}.

The full invocation is slightly more complicated:

@example
become [@var{option}@dots{}] [@var{env-var}@dots{}] @var{user} [@var{command} [@var{arg}@dots{}]]
@end example

Actually, the @var{option}s, @var{env-var}s and @var{user} can be in any
order -- the important point is that all of them appear before the
@var{command}, if there is one.

@menu
* Terminology::                 Some important terms defined
* Environment::                 Login styles and environment variables
* Group permissions::           How Become handles group permissions
* X authority::                 Problems with X authority files
* Running commands::            Running commands other than a shell
@end menu



@node Terminology, Environment, Becoming someone else, Becoming someone else
@section Terminology

The following terms get used quite a bit in the following text:

@table @asis
@item request
An invocation of Become, asking permission to become another user.

@item old user
The (real) user id of the process which invoked Become; usually, this will be
your normal user id.

@item target user
The user whom you want to become, named in a request.
@end table



@node Environment, Group permissions, Terminology, Becoming someone else
@section 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.

@menu
* New environment variables::   Become adds some useful environment variables
* Login styles::                Choose how Become sets the environment
* Tweaking the environment::    Altering individual environment variables
* Removed variables::           Some environment variables aren't passed on
@end menu


@node New environment variables, Login styles, Environment, Environment
@subsection 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.

@table @code
@item 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.

@item BECOME_HOME
The home directory of the target user.  It can be handy to read startup and
other configuration files from here.

@item BECOME_OLD_USER
The name of the user who invoked Become.

@item BECOME_OLD_HOME
The home directory of the `old' user.

@item 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 @code{BECOME_OLD_USER}; otherwise it leaves it
unchanged.

@item 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 @code{BECOME_OLD_HOME}; otherwise, it leaves
it unchanged.
@end table

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.



@node Login styles, Tweaking the environment, New environment variables, Environment
@subsection 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:

@table @code
@item -e
@itemx --preserve
The original style: try to preserve the existing user's environment as much
as possible.

@item -s
@itemx --set-user
Set some user-specific variables, like @code{USER} and @code{HOME} to reflect
the target user rather than the old user.  All other variables are preserved.

@item -l
@itemx --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.
@end table

The various styles, and the reasons behind them, are described below.

@menu
* The preserve style::          Preserve the current environment
* The set-user style::          Set user-specific variables (like @code{su})
* The login style::             Clear the environment (like @code{login})
@end menu


@node The preserve style, The set-user style, Login styles, Login styles
@subsubsection 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
@code{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 @code{USER} or
@code{LOGNAME} for the user name, and @code{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 @code{BECOME_USER} is someone else, and read in
appropriate definitions.  For example, a `bash' user might say something like
this in her @file{.bashrc}:

@example
if [ -n "$BECOME_HOME" ]; then . $BECOME_HOME/.bashrc
@end example

@noindent
Similarly, a C shell user (either `tcsh' or `csh') might say something like

@example
if ($?BECOME_HOME) source $@{BECOME_HOME@}/.cshrc
@end example

(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.)


@node The set-user style, The login style, The preserve style, Login styles
@subsubsection 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
@code{su} command.  Unless they've been preserved explicitly (@pxref{Tweaking
the environment}), `set-user' mode sets the following environment variables:

@table @code
@item USER
@itemx LOGNAME
The name of the target user.

@item HOME
The home directory of the target user.

@item SHELL
The target user's default shell
@end table

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.


@node The login style,  , The set-user style, Login styles
@subsubsection 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 (@pxref{Tweaking the environment}).  However, the following
variables are retained:

@itemize @bullet
@item
TERM
@item
DISPLAY
@item
TZ
@end itemize

@noindent
It will set the following variables:

@table @code
@item USER
@itemx LOGNAME
The name of the target user.

@item HOME
The home directory of the target user.

@item SHELL
The target user's default shell

@item MAIL
An educated guess at where the target user's mailbox is.
@end table

By default, it runs the target user's shell, informing it that this is a
login by setting the first character of @code{argv[0]} to @samp{-}.

Become makes no entries in the @file{utmp} and @file{wtmp} files.



@node Tweaking the environment, Removed variables, Login styles, Environment
@subsection 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:

@itemize @bullet
@item
Set a variable called @var{var} to a value @var{value}, by saying

@example
@var{var}=@var{value}
@end example

@noindent
The variable is preserved from automatic deletion by the login-style rules.

@item
Delete a variable called @var{var} from the environment, by saying

@example
@var{var}-
@end example

@item
Preserve a variable @var{var} from being deleted or modified by Become's
login-style rules, but not change its value, by saying

@example
@var{var}!
@end example
@end itemize

Just to try and make this slightly more sensible, here's an example.  Suppose
I want my @code{XAUTHORITY} variable to be set when I become user `fred':

@example
become XAUTHORITY=$HOME/.Xauthority fred
@end example

@noindent
should do the job nicely.  Similarly, if I want to log in as `bob', but don't
want my @code{EDITOR} variable to change:

@example
become --login EDITOR! bob
@end example

@noindent
(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.)



@node Removed variables,  , Tweaking the environment, Environment
@subsection Variables removed from the environment

Some variables are removed from the environment which Become passes to a
program for security reasons:

@table @code
@item LD_*
@itemx SHLIB_PATH
@itemx LIBPATH
@itemx _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.

@item IFS
The shell input field separator.  Modifying this variable radically alters
the way shells parse their inputs.  (In particular, consider the case where
@code{IFS} contains @samp{/}.)

@item ENV
@itemx BASH_ENV
Used by some shells: it contains the name of a file to read on every shell
invocation.

@item KRB_CONF
@ignore
I'm not really sure what's going on here, so I'll just have to bluff my way
through.  I think that the following is more-or-less accurate, having browsed
a small amount of Kerberos-related documentation.
@end ignore
Contains the name of a Kerberos configuration file.  By manipulating this
variable, an attacker could persuade a program to believe the wrong
authentication server.
@end table

Also note that the @code{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.



@node Group permissions, X authority, Environment, Becoming someone else
@section How Become handles groups

As well as handling changes of user id, Become also changes group ids.
The exact changes Become makes are under user control.

@menu
* Primary group selection::     Setting the new primary group
* Subsidiary groups::           Setting subsidiary group memberships
@end menu


@node Primary group selection, Subsidiary groups, Group permissions, Group permissions
@subsection Choosing a new primary group

By default, the primary group is chosen according to the login style
(@pxref{Login styles}): the `preserve' style retains the current primary
group, while `set-user' and `login' styles choose the target's primary group.

You can override Become's default choice using the @code{--group} (@code{-g}
for short) option:

@example
become --group=@var{group} @dots{}
@end example

The chosen @var{group} may be either a group name or a numeric gid.  The
group must be one of the following:

@itemize @bullet
@item
Your current primary group.
@item
One of your current subsidiary groups.
@item
The target user's primary group.
@item
One of the target user's subsidiary groups.
@end itemize

Become will raise an error if this isn't the case.


@node Subsidiary groups,  , Primary group selection, Group permissions
@subsection Handling subsidiary group memberships

Subsidiary group memberships are a powerful tool for managing permissions
under Unix.  Traditionally, they tend to be tied to particular users.  Become
tries to be sightly more intelligent about group memberships.

Become has a concept of @dfn{group style}, analogous to login style
(@pxref{Login styles}).  The styles are selected by giving command line
arguments:

@table @code
@item -k
@itemx --keep-groups
Retain the existing group memberships; don't add any new groups.

@item -m
@itemx --merge-groups
Merge group memberships of the target user with the exiting memberships.

@item -r
@itemx --replace-groups
Replace the existing group memberships with the target user's memberships.
@end table

Again, the defaults are dependent on the chosen login style.  Both `preserve'
and `set-user' merge group memberships; the `login' style replaces the set of
groups.

Note that you can do perverse things like replace all the subsidiary groups
but retain your primary group (using the @code{--group} option;
@pxref{Primary group selection}) if you like: Become won't try to stop you.



@node X authority, Running commands, Group permissions, Becoming someone else
@section Considerations for X authority

Other users can't read your @file{.Xauthority} file, if you have one.  This
is as it should be: anyone who can read it can connect to your X server and
read or generate events.  However, once you've become another user, you can't
open any X windows; this can be annoying if your favourite editor is X-based.

There are two basic approaches.  Either you can send the shared account a
copy of your display's magic cookie, or you can retain permission to read the
cookie file.

Be aware that allowing a shared account to connect to your X display is a
security risk.

@menu
* The user-group method::       A fairly secure way of handling X authority
* Using xauth::                 A less secure method, which might be easier
@end menu


@node The user-group method, Using xauth, X authority, X authority
@subsection The user-group method for handling X authority

This method is secure only if your site uses the `user-group' system.  In
this system, each user is allocated a group containing only that user.
Usually this is made the user's default primary group, although that's not
necessary here.

When you start a new X session, ensure that your cookie file is owned by you
and your private group.  Change the file's permissions so that it's group
readable.  Finally, ensure that your private group is retained when you
become someone else (@pxref{Group permissions}), and that the
@code{XAUTHORITY} variable is set correctly.

Note that Unix's security mechanisms aren't designed to prevent processes
owned by the same user from interfering with each other.  This method does
not provide complete security.

The following Bourne shell code in a @file{.xinitrc} should do most of the
work:

@example
XAUTHORITY="$HOME/.Xauthority"
export XAUTHORITY
chgrp mygroup $XAUTHORITY
chmod 640 $XAUTHORITY
@end example

@noindent
In a C shell, this becomes

@example
setenv XAUTHORITY $@{HOME@}/.Xauthority
chgrp mygroup $XAUTHORITY
chmod 640 $XAUTHORITY
@end example

The @code{XAUTHORITY} file is preserved by both the `preserve' and `set-user'
login styles, so this isn't a problem.  You can now become other users, and
your X permissions will follow you around correctly.

It's probably worth noting that the @code{xauth} program annoyingly resets
the permissions on the cookie file every time it writes to it.  This will be
particularly irritating if you use @code{ssh}'s X forwarding capabilities,
because every @code{ssh} connection will reset the permissions.  You can deal
with this problem by putting a line

@example
chmod 640 $@{XAUTHORITY-$HOME/.Xauthority@} 2>/dev/null
@end example

@noindent
in your @file{.bashrc} or @file{.profile} (for Bourne-like shell users) or

@example
if ($?XAUTHORITY) then
  chmod 640 $XAUTHORITY >&/dev/null
else
  chmod 640 $@{HOME@}/.Xauthority >&/dev/null
endif
@end example

@noindent
in @file{.cshrc} for C shell users.


@node Using xauth,  , The user-group method, X authority
@subsection The @code{xauth} method for handling X authority

This method sends your X cookie to the shared account.  It's therefore
intrinsically dangerous: you must be able to trust the other users of the
shared account not to take undue advantage of this situation.

The following (Bourne) shell snippet illustrates how you might send an
authorisation cookie to the shared account, to allow it to connect to your
display:

@example
if test -n "$BECOME_HOME"; then
  XAUTHORITY="$BECOME_HOME/.Xauthority"; export XAUTHORITY
elif test -n "$DISPLAY" && test -z "done_xauth_cookie"; then
  case "$DISPLAY" in
    :0.0) display=`hostname`:0.0 ;;
    *) display="$DISPLAY" ;;
  esac
  xauth extract - $display | \
    become someone -c 'xauth -f $BECOME_HOME/.Xauthority merge -'
  done_xauth_cookie=yes; export done_xauth_cookie
fi
@end example

The equivalent C shell code is

@example
if ($?BECOME_HOME) then
  setenv XAUTHORITY "$@{BECOME_HOME@}/.Xauthority
else if ($?DISPLAY && ! $?done_xauth_cookie) then
  if ($DISPLAY == :0.0) then
    set display="`hostname`:0.0"
  else
    set display="$DISPLAY"
  endif
  xauth extract - $display | \
    become someone -c 'xauth -f $BECOME_HOME/.Xauthority merge -'
endif
@end example

It works as follows:

@itemize @bullet
@item
If the variable @code{BECOME_HOME} is set, then we're probably really someone
else, so point to the shared account's authority file.

@item
Otherwise, check to see whether we have a display, and the authorisation has
not already been sent.  If this is so, resolve a local display name into a
remote one (just in case) and then send it to the shared account.
@end itemize



@node Running commands,  , X authority, Becoming someone else
@section Executing specific commands

As well as starting shells, Become can run single commands.  This can be
useful in two ways:

@itemize @bullet
@item
It enables Become to be used in scripts.

@item
It allows access to shared accounts to be controlled on the basis of the
command to be run.
@end itemize

To run a command as another user, say:

@example
become @var{user} @var{command} [@var{argument}@dots{}]
@end example

If the request is granted, Become runs @var{command}, passing it any
arguments following the command name.  Become doesn't run a shell, so there's
no extra escaping which needs to be done.

If you really want to run a shell command as another user, you can use the
@code{-c} option:

@example
become @var{user} -c @var{shell-command}
@end example

This is exactly equivalent to

@example
become @var{user} /bin/sh -c @var{shell-command}
@end example

in every way.  In particular, you must have permission to run @file{/bin/sh}
as @var{user} for it to work: Become doesn't attempt to interpret the shell
command in any way.  Also note that Become always uses the Bourne shell,
regardless of your current shell preference, or @var{user}'s default shell.
(This is done to provide a stable programming interface which works
irrespective of changes to the shared account's configuration.)


@c --------------------------------------------------------------------------
@node Administering Become, Invoking Become, Becoming someone else, Top
@chapter Become administration


This chapter will explain how Become is administrated and maintained.

@menu
* Configuration files::         Overview of Become's configuration files
* Standalone or networked::     The two main types of Become installations
* The configuration file::      How to define who's allowed to do what
* Networked configuration::     Considerations for networked installations
@end menu



@node Configuration files, Standalone or networked, Administering Become, Administering Become
@section Configuration files

Become keeps its configuration and administrative files in a directory
usually named @file{/etc/become}, although this can be changed with the
@code{--with-etcdir} option to the configuration script when you build
Become.

Not all of the files are needed on all machines.

@table @file
@item become.conf
The main configuration file, containing a description of which users are
allowed to become which other users, where, and what they're allowed to run
when they get there.  Only needed on servers or standalone machines.

@item become.server
A list of servers to contact.  Only needed on client machines.

@item become.key
The signing key to use when sending requests to servers.  Needed on servers,
but not on standalone machines.

@item become.pubkey
The verification keys to use when checking server responses.  Needed on
clients, but not on standalone machines.

@item become.pid
The process id of the server.  Created automatically by Become's server when
in starts up.
@end table


@node Standalone or networked, The configuration file, Configuration files, Administering Become
@section Installation types


Become can be installed in two different ways, depending on how you want to
administer it:

@itemize @bullet
@item
In a @dfn{standalone} installation, each Become request is dealt with
locally: the program reads the configuration file, and decides whether it
should grant or deny permission.

Standalone installations don't depend on servers being available, or even on
the existence of a network.  They're useful for small sites, or sites with a
small number of users.  The disadvantages are that reading the configuration
file takes a while, so the program doesn't feel as responsive as it should,
and ensuring that all the hosts' configuration files are synchronised becomes
difficult when you have lots of machines.

@item
In a @dfn{network} installation, any Become requests are sent on to a
collection of servers.  The servers analyse the request and send a reply back
which either authorises or forbids access.

A networked installation clearly depends on the servers' reliability.  The
client reacts only to the first reply it receives, so as long as there is one
server running, everything should continue as normal.

A networked installation is useful when you have a large number of client
machines, particularly ones which may not be awake all the time.  The full
configuration file only needs to be installed on a small number of servers;
the clients require only a list of server machines to contact, and an
encryption key to use.
@end itemize



@node The configuration file, Networked configuration, Standalone or networked, Administering Become
@section The configuration file

The main configuration file, usually called @file{/etc/become/become.conf},
contains all the rules which Become uses to decide whether to grant or deny
requests.  It may also contain additional information for the benefit of
Become daemons, if you're using a networked installation.

@menu
* Requests and rules::          How the configuration file works
* Basic syntax::                Quick overview of Become's syntax
* Classes::                     Defining classes of things
* Predefined classes::          Become predefines some (maybe) useful classes
* Allow statements::            Allow users to become other users
* Other statements::            Some other useful statements
* Example configuration file::  An example, showing a few features.
* Checking and querying::       Checking and querying configuration files
* Complete grammar::            Complete grammar for Become config files
@end menu


@node Requests and rules, Basic syntax, The configuration file, The configuration file
@subsection Requests and rules

Become looks at four pieces of information when it's analysing a request:

@itemize @bullet
@item
the user's current identity;
@item
the identity the user wishes to assume;
@item
the host which generated the request; and
@item
the command the user wishes to run.
@end itemize

Each of these pieces of information is looked at when Become decides whether
to honour a request.

The configuration file's main purpose is to describe the conditions under
which Become should honour a request.  These conditions are described by a
number of @emph{rules}.  A rule consists of two lists of users (called `from'
and `to'), a list of hosts, and a list of commands.  A rule matches a request
if:

@itemize @bullet
@item
the user's current identity is in the rule's `from' list;
@item
the target user's identity is in the rule's `to' list;
@item
the host is in the rule's host list; and
@item
the command to be run is in the rule's command list.
@end itemize

A request is honoured if there is a rule which matches the request.


@node Basic syntax, Classes, Requests and rules, The configuration file
@subsection Basic configuration file syntax

The configuration file consists of a sequence of statements, each terminated
by a semicolon.

Comments begin with a @samp{#} character, and continue to the end of the
line.  This is the only time newlines behave specially: newlines behave just
like any other whitespace characters within statements.

Strings are enclosed in double-quote characters (@samp{"}).  Within a string,
a backslash causes the following character to be treated literally, whatever
it may be (including quotes, backslashes and newlines).

Names begin with an alphabetic character or an underscore, and consist of
letters, digits and underscores.


@node Classes, Predefined classes, Basic syntax, The configuration file
@subsection Classes

A @dfn{class} in Become is a set of users, hosts or commands.  You can define
and name your own classes using statements of the form:

@example
user @var{name} = @var{class-expr} ;
command @var{name} = @var{class-expr} ;
host @var{name} = @var{class-expr} ;
@end example

A @var{class-expr} is an expression defining a class.  You can build a
complex class out of simple classes using the operators (in ascending
precedence order) @samp{,}, @samp{-}, @samp{|} and @samp{&}, which represent
the set options `union', `subtraction', `union' (again!), and `intersection'.
Subexpressions can be parenthesised to override the default precedence.
Once a class name has been defined, as shown above, it can be used in
subsequent class expressions.

A single user may be designated by either a user name (in quotes) or an
integer uid.  Commands and hosts may be designated by quoted strings which
may contain wildcards.  Host strings are matched against both numeric (dotted
quad) IP addresses and the reverse-resolved hostname.  Command strings are
matched against the absolute pathname of the command the user wants to
execute.



@node Predefined classes, Allow statements, Classes, The configuration file
@subsection Predefined classes

In an attempt to make life a bit easier, Become creates a collection of
predefined classes.

The standard classes @code{all} and @code{none} match anything and nothing
respectively.  The @code{all} class is useful in some contexts: it gives you
a way of saying `everything except@dots{}', for example:

@example
user MUNDANES = all - SYSHACKS;
@end example

@noindent
The @code{none} class is provided because it's needed internally anyway and
someone might come up with a use for it.

Become also defines some other classes:

@itemize @bullet
@item
For each username @var{user}, Become adds a class called @samp{@var{user}}
which matches just that user.

@item
For each group name @var{group}, Become creates a class called
@samp{@var{group}} which matches any user who is a member of that group.

@item For each netgroup @var{netgroup}, Become creates two classes:
@samp{u_@var{netgroup}} which matches any user listed in the netgroup, and
@samp{h_@var{netgroup}} which matches any host listed in the netgroup.
@end itemize

If a name is used for both a user @emph{and} a group, then corresponding
class ends up containing the user together with all of the group members.
For this reason, it's probably better to use the predefined classes for
groups rather than individual users -- use quoted user names for individual
users.

Note that users and groups are read using the standard @code{get*ent} calls
@emph{and} directly from the NIS server (if there is one).  The idea here is
that a Become server can be run on a machine which allows restricted logins.
It still needs to know about all the users known to the outside world.

Netgroups are read only from the NIS servers.  In particular, although GNU
systems allow netgroup databases to be stored in local files, Become won't
read them because there's no defined interface for enumerating netgroups.


@node Allow statements, Other statements, Predefined classes, The configuration file
@subsection Allow statements

The @code{allow} statement defines the rules Become uses when deciding
whether to grant a request; see @ref{Requests and rules}.

@example
allow [[@var{host-class}]] [@var{user-class}] -> [@var{user-class}] [ : @var{command-class}]
@end example

(The @var{host-class} is optional, but must be enclosed in square brackets if
present.)

The four classes in an allow statement are called, respectively, the `host',
the `to-user', the `from-user' and the `command'.  Any of the four classes
may be omitted, and an omitted class defaults to `all'.

When a request is received, Become checks the fields in the request against
the classes in each allow statement of the configuration file.  If a
statement matches, the request is granted; if there are no full matches,
the request is denied.


@node Other statements, Example configuration file, Allow statements, The configuration file
@subsection Other statements

Two other statement types are defined.  They only have an effect on Become in
daemon mode:

@example
port @var{port} ;
keyfile @var{key-file} ;
@end example

@noindent
The @code{port} statement specifies the port to which the server should
listen; the @var{port} may be be an integer or a quoted service name.  The
@code{keyfile} statement instructs Become to use the key from the file named
@var{key-file}, which must be a quoted string.


@node Example configuration file, Checking and querying, Other statements, The configuration file
@subsection An example configuration file

@example
#
# become.conf
#
# Example configuration file
#

allow wheel -> "root";

user NEWS = "fred", "jim";
allow NEWS -> "news";

user HTTP = "jim", "bob";
allow ["www.somewhere.com"]
        HTTP -> "httpd" : "/bin/kill", "/etc/init.d/httpd";
@end example


@node Checking and querying, Complete grammar, Example configuration file, The configuration file
@subsection Checking and querying the configuration file

At a reasonably sized site, Become configuration files can get rather large,
and becomes tricky to work out exactly who's allowed to do what and where.

The @code{bcquery} tool provided allows Become configuration files to be
verified and queried.  It can be used to ensure that a file is syntactically
correct before it is deployed, or to enquire about privileges granted.

@menu
* Verifying config files::      Checking a configuration file is correct
* Querying config files::       Asking questions about privileges
* Output formats::              Different ways of formatting output
* Restricting output::          Being selective about what gets output
* bcquery reference::           Complete command line reference
@end menu

@node Verifying config files, Querying config files, Checking and querying, Checking and querying
@subsubsection Verifying configuration files

A common use of @code{bcquery} is to ensure that a configuration file is
actually valid.  The command

@example
bcquery [-file @var{file}] -check
@end example

@noindent
verifies that a configuration file conforms to Become's expectations.  If
there are any errors in @var{file}, they are reported, and @code{bcquery}
will return a nonzero exit code.

If no @var{file} is specified, @code{bcquery} will read the configuration
file which Become itself reads by default, usually
@code{/etc/become/become.conf}.


@node Querying config files, Output formats, Verifying config files, Checking and querying
@subsubsection Querying configuration files

The @code{bcquery} program will list all rules which match a selected request
pattern.  For example, you can display all rules which allow a particular
user to change identity, or all rules which allow people to assume root
privileges on a particular host.

@example
bcquery [-file @var{file}] @var{query}
@end example

The following simple queries are supported:

@table @asis
@item @code{-from} @var{user}
Matches any rule containing @var{user} in its `from' list.
@item @code{-to} @var{user}
Matches any rule containing @var{user} in its `to' list.
@item @code{-host} @var{host}
Matches any rule containing @var{host} in its host list.
@item @code{-command} @var{cmd}
Matches any rule containing @var{cmd} in its `command' list.
@end table

@noindent
Simple queries can be combined using the following operators:

@table @asis
@item @var{query-a} @code{-or} @var{query-b}
Matches a rule matched by either @var{query-a} or @var{query-b}.
@item @var{query-a} @code{-and} @var{query-b}
Matches a rule matched by both @var{query-a} and @var{query-b}.
@item @code{-not} @var{query}
Matches a rule which is not matched by @var{query}.
@item @code{(} @var{query} @code{)}
Matches a rule matched by @var{query} (overrides default precedence).
@end table

The @code{-and}, @code{-or} and @code{-not} operators may be written
@code{&}, @code{|} and @code{!} respectively, if you prefer, and the
@code{-and} operator is optional.  These characters (and the parentheses
@code{(} and @code{)}) may need to be quoted to prevent interpretation by the
shell.

Some examples may explain what's going on:

@table @samp
@item bcquery -from hacker
Displays all rules applying to user `hacker'.
@item bcquery -host somehost -to root
Displays rules allowing people to become root on @code{somehost}.
@end table


@node Output formats, Restricting output, Querying config files, Checking and querying
@subsubsection Output formats

The @code{bcquery} program has two distinct output formats: `rows' and
`columns'.

The `columns' format is probably the simpler to understand, and certainly the
easier to read.  Each matching record is displayed with the lists of users,
hosts and commands in columns.  A query on the example configuration file
(@pxref{Example configuration file}) is shown below:

@example
FROM            TO              HOST                     COMMAND

frankie         root            ALL                      ALL
selina

fred            news            ALL                      ALL
jim

jim             httpd           www.somewhere.com        /bin/kill
bob                                                      /etc/init.d/httpd
@end example

@noindent
The `columns' format can only show simple lists.  A more complex class
definition will show up as @samp{<complex>} in a `columns' format listing.

The `rows' format is capable of displaying classes in their full generality,
but is harder to parse and read.  It displays each list in the form of an
expression, in more or less the same syntax as a class definition
(@pxref{Classes}).

The default behaviour is to use `columns' format where possible, or `rows'
format if some of the lists are too complex to be represented in columns.
You can select a format explicitly using the @code{-columns} or @code{-rows}
options, which is useful if you're trying to parse the output of
@code{bcquery} with a script.


@node Restricting output, bcquery reference, Output formats, Checking and querying
@subsubsection Restricting output

It's also possible to suppress bits of information about each matched rule.
For example, you can show only the `from' list, or just the `to' and `host'
lists.  This is done with the @code{-output} option.

Each list is given a letter; the `from' list is called @samp{f}, the `to'
list @samp{t}, the host list @samp{h} and the command list @samp{c}.  You can
select which lists are displayed by giving the corresponding letters (the
order isn't important).  You can also turn individual lists on or off by
preceding the characters with @samp{+} or @samp{-} characters.  If you start
with a @samp{+} or @samp{-}, then the last-set selection (or the initial
default of all-lists-enabled) is modified.

For example, @samp{-output ftc} shows only the `from', `to' and `command'
lists.  This could be written @samp{-output -h} too, to turn the hosts list
off.

This option is mainly useful with the `columns' output format (@pxref{Output
formats}) to save scripts having to select columns out themselves.


@node bcquery reference,  , Restricting output, Checking and querying
@subsubsection @code{bcquery} options summary

@example
bcquery [@var{option}@dots{}] [@var{query}]
@end example

The @var{option}s available are:

@table @asis
@item @code{-help}
Displays a summary of the available options, and exits.

@item @code{-file} @var{file}
Read @var{file}, rather than the compiled-in default (usually
@file{/etc/become/become.conf}).

@item @code{-dump}
Don't read a configuration file.  Instead, display the query tree parsed from
the command line.  This is a debugging feature.

@item @code{-check}
Don't attempt to output any rules.  Instead, just check the configuration
file for validity.

@item @code{-output} @var{spec}
Selects which columns are to be displayed for each matching rule.
For full details, see @ref{Restricting output}.

@item @code{-columns}
@itemx @code{-rows}
Forces `columns' or `rows' output format.  @xref{Output formats}.

@item @code{-nohead}
Suppress the header line at the top of the output in `columns' mode.  Makes
the output more amenable to automatic processing (but harder to read).

@item @code{-from} @var{user}
@itemx @code{-to} @var{user}
@itemx @code{-host} @var{hostname}
@itemx @code{-command} @var{cmd}
Simple queries for selecting rules.  @xref{Querying config files}.

@item @code{-and}
@itemx @code{-or}
@itemx @code{-not}
Operators for combining queries into something useful.  @xref{Querying config
files}.
@end table


@node Complete grammar,  , Checking and querying, The configuration file
@subsection Complete grammar for configuration files

@format
@var{file} ::= @var{file} @var{statement}

@var{statement} ::= @var{class-def}
        | @var{allow-spec}
        | @var{port-spec}
        | @var{key-spec}

@var{class-def} ::= @samp{user} @var{name} = @var{class-expr} @samp{;}
        | @samp{command} @var{name} = @var{class-expr} @samp{;}
        | @samp{host} @var{name} = @var{class-expr} @samp{;}

@var{allow-spec} ::= @samp{allow} @var{opt-host-spec} @var{opt-user-spec}
                @samp{->} @var{opt-user-spec} @var{opt-command-spec} @samp{;}

@var{opt-host-spec} ::= @samp{[} @var{class-expr} @samp{]}
        | @var{empty}

@var{opt-user-spec} ::= @var{class-expr}
        | @var{empty}

@var{opt-command-spec} ::= @samp{:} @var{class-expr}
        | @var{empty}

@var{port-spec} ::= @samp{port} @var{integer} @samp{;}
        | @samp{port} @var{string} @samp{;}

@var{key-spec} ::= @samp{keyfile} @var{string} @samp{;}

@var{class-expr} ::= @var{class-diff-expr}
        | @var{class-expr} @samp{,} @var{class-diff-expr}

@var{class-diff-expr} ::= @var{class-isect-expr}
        | @var{class-diff-expr} @samp{-} @var{class-union-expr}

@var{class-union-expr} ::= @var{class-isect-expr}
        | @var{class-union-expr} @samp{|} @var{class-isect-expr}

@var{class-isect-expr} ::= @var{class-primary}
        | @var{class-isect-expr} @samp{&} @var{class-primary}

@var{class-primary} ::= @samp{(} @var{class-expr} @samp{)}
        | @var{string}
        | @var{integer}

@var{integer} ::= one or more digits (@samp{0}--@samp{9})

@var{name} ::= an alphabetic character or underscore, followed by zero or
                more alphanumeric characters or underscores

@var{string} ::= @samp{"} @var{string-chars} @samp{"}

@var{string-chars} ::= @var{string-chars} @var{string-char}
        | @var{empty}

@var{string-char} ::= a @samp{\} followed by any character
        | any character other than @samp{"}, @samp{\} or newline

@var{empty} ::=
@end format



@node Networked configuration,  , The configuration file, Administering Become
@section Networked configuration

If you're planning to use Become in a standalone way, you can skip this
section.

@menu
* Choosing servers::            Which servers Become tries to talk to
* Setting up keys::             How to generate keys for Become
* Issuing a new key::           How to issue new keys without disruption
@end menu


@node Choosing servers, Setting up keys, Networked configuration, Networked configuration
@subsection Choosing servers

Become notices that it's meant to send requests to a server if it finds a
@file{become.server} file.  This file contains entries of the form

@example
@var{host} [: @var{port}]
@end example

If the @var{port} is omitted, Become chooses a port by looking at the
services database for a service which matches the name by which Become was
invoked: normally this will be @samp{become}.

Become sends a request to all of the servers and believes the first valid
reply it receives.  Since servers ignore requests they believe to be invalid,
this enables you to change Become's key without disrupting service
(@pxref{Issuing a new key}).

If you're using NIS, you should try to ensure that Become servers runs only
on NIS servers; the NIS master is probably a good choice.

Become isn't particularly processor-intensive, and doesn't seem to require
very much memory.


@node Setting up keys, Issuing a new key, Choosing servers, Networked configuration
@subsection Setting up keys

Communication between Become clients and the server is encrypted to ensure
that it's not feasible to gain unauthorised privilege by subverting the
network.  Become uses the DSA algorithm to ensure authenticity of replies.

Each client machine, and the server, must have a copy of the same key.  The
key is usually stored in @file{/etc/become/become.key}.  Become's keys are
128 bits long.

The key file can be generated using Catacomb's @code{key} program.  The
commands

@example
key -k /etc/become/become.key add -adsa -e"now + 1 year" become-dsa 
key -k /etc/become/become.key extract -f -secret /etc/become/become.pubkey
@end example

@noindent
will generate a suitable DSA key, and extract the public part.  You should
install the public key on all of your client computers, writable only by
root.  The private key should be only on the server, and readable or writable
only by root.

If you have multiple servers, they can all have different private keys.
You'll need to put all of the public keys in the
@file{/etc/become/become.pubkey} file. 


@node Issuing a new key,  , Setting up keys, Networked configuration
@subsection Issuing a new key

When you're sending out a new key, you run a risk of disrupting service.  The
server reads a new key; the clients still have the old one.

We used to recommend running two servers.  Now, however, you can generate the
new key, install the new public key on the clients in addition to the old
one, and then install the new private key on the server.  The clients try all
valid public keys when attempting to authenticate a response, so this
approach will work.


@c --------------------------------------------------------------------------
@node Invoking Become,  , Administering Become, Top
@chapter Invoking Become


This chapter provides an exhaustive description of Become's command line
options, organised in a reference-manual sort of way.

@menu
* Becoming another user::       Options for becoming another user
* Starting Become daemons::     Options for starting Become daemons
* Debugging options::           Options to use when Become goes wrong
@end menu



@node Becoming another user, Starting Become daemons, Invoking Become, Invoking Become
@section Becoming another user

@subsection Synopsis

@example
become [@var{option}@dots{}] [@var{env-var}@dots{}] @var{user} [@var{command} [@var{argument}@dots{}]]
@end example

Actually, you can put the @var{option}s, @var{env-var}s and @var{user} in any
order you like; the important thing is that all of them appear before the
command, if any.


@subsection Usage

The @var{option}s appropriate for this mode are as follows:

@table @code
@item -h
@itemx --help
Display a (fairly verbose) help message describing the various command line
options and exits successfully.

@item -u
@itemx --usage
Display a terse summary of the command line options and exits successfully.

@item -v
@itemx
Display's Become's version number and exits successfully.

@item -e
@item --preserve-environment
Selects the `preserve' login style (@pxref{The preserve style}).  All
environment variables are preserved.  The default command is the current
user's own shell.  The default primary group becomes the current primary
group; the default group style is set to `merge'.

@item -s
@itemx --su
@itemx --set-user
Selects the `set-user' login style (@pxref{The set-user style}).  Most
environment variables are preserved, but @code{USER}, @code{LOGNAME},
@code{HOME} and other user-specific variables are altered to reflect the
target user's configuration.  The default command is the target user's shell.
The default primary group becomes the target user's primary group; the
default group style is set to `merge'.

@item -l
@itemx --login
Selects the `login' login style (@pxref{The login style}).  The environment
is cleared and rebuilt, in a similar way to the behaviour of @code{login}.
The default command is the target user's shell.  The default primary group
becomes the target user's primary group; the default group style is set to
`replace'.

@item -g @var{group}
@itemx --group=@var{group}
Selects @var{group} as the primary group; it may be either a group name or a
numeric group id.  Note that @var{group} must be the primary group or
a subsidiary group of either the current user or the target user.

@item -k
@itemx --keep-groups
Selects the `keep' group style (@pxref{Subsidiary groups}).  The current set
of subsidiary group memberships are passed on unchanged.

@item -m
@itemx --merge-groups
Selects the `merge' group style (@pxref{Subsidiary groups}).  The current set
of subsidiary group memberships are merged with the subsidiary groups of the
target user.

@item -r
@itemx --replace-groups
Selects the `replace' group style (@pxref{Subsidiary groups}).  The target
user's subsidiary group memberships are passed on; the current subsidiary
groups are discarded.

@item -c @var{shell-cmd}
@itemx --command=@var{shell-cmd}
Sets the @var{command} and @var{argument}s to invoke
@code{/bin/sh -c @var{shell-cmd}}; i.e., to execute a Bourne shell command
instead of just @code{exec}ing a program.  Note that permissions are checked
for executing the Bourne shell @code{/bin/sh}; the contents of the
@var{shell-cmd} are not inspected.
@end table

The @var{env-var} arguments fine-tune the environment passed to the command.
Each @var{env-var} setting must be one of the following:

@table @code
@item @var{var}=@var{value}
Assign the variable named @var{var} the value @var{value}.  Protect the
variable @var{var} from modifications by the login style.

@item @var{var}!
Protect the variable @var{var} from modifications by the login style, but
don't change its value.

@item @var{var}-
Remove the variable @var{var} from the environment; do not pass it on.
@end table

The @var{user} specifies the user as whom the @var{command} should be
executed (i.e., the @dfn{target user}).  It may be a user name or a numeric
user id.

The @var{command} specifies a command to execute.  If @var{command} does not
contain a path, it is looked for using the current @code{PATH} environment
variable.  The resulting pathname is canonified if necessary, to produce an
absolute pathname.  Note that symbolic links are @emph{not} resolved -- this
prevents an attack whereby a user could invoke a program, passing it an
unusual @code{argv[0]} which might cause unusual behaviour.

The @var{command} name is used both as the command to execute and passed to
the command as @code{argv[0]}.  It is not possible to specify an alternative
value to be passed as @code{argv[0]}.  Subsequent arguments, if supplied, are
passed as @code{argv[1]} upwards.

If no @var{command} is given, a shell is invoked; the particulars of the
shell are determined by the login style (see above).

The @var{command} is executed as follows:

@itemize @bullet
@item
The subsidiary groups are chosen as determined by the group style.
@item
The real and effective gids are set.
@item
The real and effective uids are set.
@item
The @var{command} is called using the standard @code{execve} system call.
@end itemize



@node Starting Become daemons, Debugging options, Becoming another user, Invoking Become
@section Starting Become daemons

@subsection Synopsis

@example
become --daemon [@var{option}@dots{}]
@end example


@subsection Usage

The following options are appropriate to this mode:

@table @code
@item -h
@itemx --help
Display a (fairly verbose) help message describing the various command line
options and exits successfully.

@item -u
@itemx --usage
Display a terse summary of the command line options and exits successfully.

@item -v
@itemx
Display's Become's version number and exits successfully.

@item -d
@itemx --daemon
Start a Become server, instead of processing a request.  Become will read its
command line options, read in the configuration file (and verify that it's
correct) and then fork into the background to wait for incoming requests.
Become relinquishes all setuid privileges (by setting all uids to the real
uid) when it enters daemon mode.  It is therefore only really useful to run a
daemon as the superuser.

@item -p @var{port}
@itemx --port=@var{port}
Listen for requests on @var{port}.  This option is overridden by the
@code{port} option in the configuration file.

@item -f @var{file}
@itemx --config-file=@var{file}
Read configuration from @var{file}, instead of the default (set at
compile time, usually @file{/etc/become/become.conf}).
@end table

The syntax of the configuration file is described in @ref{The configuration
file}.


@node Debugging options,  , Starting Become daemons, Invoking Become
@section Debugging options

Some options are only useful when trying to find out why Become is
misbehaving.  Of course, this never happens, so here are the options which
you won't need to use:

@table @code
@item -T[@var{file}]
@itemx --trace[=@var{file}]
Write trace information to @var{file} (or to standard output, if no
@var{file} is specified).  You must be able to create the file and open it
for writing.

@item -L[@var{feature}...]
@itemx --trace-level[=@var{feature}]
Selects which features Become ought to trace.  Each feature is allocated a
letter; simply string together the letters for the features you want to
debug.  The letters @samp{D} and @samp{A} stand respectively for `default'
and `all' features; you can subtract from them by saying, for example,
@samp{A-xyz} to select all features except @samp{x}, @samp{y} and @samp{z}.
The exact list of features supported at any one time can be listed by giving
the @code{--trace-level} option without an argument.

@item -I @var{user}
@itemx --impersonate=@var{user}
Pretend to be @var{user} instead of yourself when the request is checked.
This option can only be used if it wasn't disabled at compile-time and if
Become is not running setuid.  Even so, Become will only inform you of the
outcome; it will not execute any commands.
@end table



@c --------------------------------------------------------------------------

@c --- No index yet ---
@c
@c @node Concept index,  , Invoking Become, Top
@c @unnumbered Concept index
@c @printindex cp
@c 
@contents

@bye

@c ----- That's all, folks --------------------------------------------------