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

1.4 Considerations for X authority

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.


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

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

1.4.2 The 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:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]

This document was generated by Mark Wooding on March, 14 2006 using texi2html 1.76.