[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Other users can't read your `.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.
1.4.1 The user-group method for handling X authority | A fairly secure way of handling X authority | |
1.4.2 The xauth method for handling X authority | A less secure method, which might be easier |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 (see section How Become handles groups), and that the
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 `.xinitrc' should do most of the work:
XAUTHORITY="$HOME/.Xauthority" export XAUTHORITY chgrp mygroup $XAUTHORITY chmod 640 $XAUTHORITY |
In a C shell, this becomes
setenv XAUTHORITY ${HOME}/.Xauthority chgrp mygroup $XAUTHORITY chmod 640 $XAUTHORITY |
The 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 xauth
program annoyingly resets
the permissions on the cookie file every time it writes to it. This will be
particularly irritating if you use ssh
's X forwarding capabilities,
because every ssh
connection will reset the permissions. You can deal
with this problem by putting a line
chmod 640 ${XAUTHORITY-$HOME/.Xauthority} 2>/dev/null |
in your `.bashrc' or `.profile' (for Bourne-like shell users) or
if ($?XAUTHORITY) then chmod 640 $XAUTHORITY >&/dev/null else chmod 640 ${HOME}/.Xauthority >&/dev/null endif |
in `.cshrc' for C shell users.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
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 |
The equivalent C shell code is
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 |
It works as follows:
BECOME_HOME
is set, then we're probably really someone
else, so point to the shared account's authority file.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Mark Wooding on March, 14 2006 using texi2html 1.76.