1

I have a vnc session and I can access X11 just by doing su - user, for other user, without the need of sux.

Also, when I am trying to switch to user, using sudo sux - user or sudo su - user, I can't access X11 and get the following error:

X11 connection rejected because of wrong authentication.

But others are working: sux and su.

Of course, I am still confused about the message sux shows:

Value of TERM has been set to "xauth -q remove localhost:100.0 2>/dev/null; xauth -q remove localhost/unix:100.0;"

  1. Why is it removing the old keys? What's the necessity?

  2. And su and sux works almost same, both are removing old keys and both works. How and why?

  3. And what's the reason for sudo su / sudo sux not working?

  • Ok, for my 2nd question, I can see from xauth info that it is using temporary authority file with only one entry of the required session's magic key, instead of using the default .Xauthority. But why? – GP92 Feb 25 '16 at 13:28
  • you need to copy the cookies from the originating user to the target. If you simply set XAUTHORITY in the target environment, you would likely not have read permission on the file (even as root, NFS-mounted home directories wouldn't work). – Toby Speight Feb 26 '16 at 9:22
2

The answer (for sux) is given in the script's comments. It is transferring the X display-cookies from your original user permissions to root's, to allow it to open the X display using those transferred permissions.

Here's a section worth reading:

  # We highjack the TERM environment variable to transfer the cookies to the
  # other user. We do this so that they never appear on any command line, and
  # because TERM appears to be the only environment variable that is not
  # reset by su. Then, as long as 'echo' is a shell builtin, these cookies
  # will never appear as command line arguments which means noone will be
  # able to intercept them (assuming they were safe in the first place).
  sux_term="TERM='$TERM'"             
  # now we can store the script that will restore the cookies on the other
  # side of the su, in TERM!

  # Remove the old cookies. They may cause trouble if we transfer only one
  # cookie, e.g. an MIT cookie, and there's still a stale XDM cookie hanging
  # around.
  export TERM="xauth -q remove $DISPLAY 2>/dev/null;"
  if [ -n "$sux_unix_display" ]
  then     
    TERM="$TERM xauth -q remove $sux_unix_display;"
  fi

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.