The Kerberos V5
ksu program replaces the standard UNIX su
ksu first authenticates you to Kerberos. Depending on
the configuration of your system,
ksu may ask for your Kerberos
password if authentication fails. Note that you should never type
your password if you are remotely logged in using an unencrypted
ksu has authenticated you, if your Kerberos principal
appears in the target's
.k5login file (see Granting Access to Your Account) or in the target's
.k5users file (see below), it
switches your user ID to the target user ID.
david has put
jennifer's Kerberos principal in his
ksu to become
david, the exchange would look like this. (To
differentiate between the two shells,
prompt is represented as
david's prompt is represented as
jennifer% ksu david Account david: authorization for jennifer@ATHENA.MIT.EDU successful Changing uid to david (3382) david%
Note that the new shell has a copy of
tickets. The ticket filename contains
.1 appended to it:
david% klist Ticket cache: /tmp/krb5cc_3382.1 Default principal: jennifer@ATHENA.MIT.EDU Valid starting Expires Service principal 07/31/04 21:53:01 08/01/04 07:52:53 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU 07/31/04 21:53:39 08/01/04 07:52:53 host/daffodil.mit.edu@ATHENA.MIT.EDU david%
jennifer had not appeared in
.k5login file (and the system was
configured to ask for a password), the exchange would have looked like
david has taken appropriate
precautions in protecting his password):
jennifer% ksu david WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. Kerberos password for david@ATHENA.MIT.EDU: <-
jennifertypes the wrong password here. ksu: Password incorrect Authentication failed. jennifer%
david did not want to give
jennifer full access to his account, but wanted to
give her permission to list his files and use the "more" command to view
them. He could create a
.k5users file giving her permission to
run only those specific commands.
.k5users file is like the
.k5login file, except that
each principal is optionally followed by a list of commands.
will let those principals execute only the commands listed, using the
might look like the following:
jennifer@ATHENA.MIT.EDU /bin/ls /usr/bin/more joeadmin@ATHENA.MIT.EDU /bin/ls joeadmin/admin@ATHENA.MIT.EDU * david@EXAMPLE.COM
.k5users file would let
jennifer run only the commands
/usr/bin/more. It would let
joeadmin run only
/bin/ls if he had regular tickets, but if he had
tickets for his
joeadmin/admin@ATHENA.MIT.EDU, he would be able
to execute any command. The last line gives
in the realm EXAMPLE.COM permission to execute any command.
(I.e., having only a Kerberos principal on a line is equivalent to
giving that principal permission to execute
*.) This is so that
david can allow himself to execute commands when he logs
in, using Kerberos, from a machine in the realm EXAMPLE.COM.
jennifer wanted to list his home directory,
she would type:
jennifer% ksu david -e ls ~david Authenticated jennifer@ATHENA.MIT.EDU Account david: authorization for jennifer@ATHENA.MIT.EDU for execution of /bin/ls successful Changing uid to david (3382) Mail News Personal misc bin jennifer%
jennifer had tried to give a different
ksu, it would have prompted for a password as with the
Note that unless the
.k5users file gives the target permission to
run any command, the user must use
ksu with the -e
ksu options you are most likely to use are:
ksu. (e.g., the user
joeadminmight want to use his
admininstance. See What is a Ticket?.)
ksunot to destroy your Kerberos tickets when
ksuneeds to obtain tickets.
ksuneeds to obtain tickets.
ksuto copy your Kerberos tickets only if the UID you are switching is the same as the Kerberos primary (either yours or the one specified by the -n option).
ksunot to copy any Kerberos tickets to the new UID.
ksuto execute command and then exit. See the description of the
ksuto pass everything after
-ato the target shell.
The full set of options to Kerberos V5
ksu are discussed
in the Reference section of this manual. (see ksu Reference)