Аутентификация X11 не работает в `sudo sux / sudo su`, но работает в` sux / su.` Почему?

У меня есть сеанс vnc, и я могу получить доступ к X11, просто выполняя su - user , для другого пользователя, без необходимости sux.

Кроме того, когда я пытаюсь переключиться на пользователя, используя sudo sux - user или sudo su - user , я не могу получить доступ к X11 и получить следующую ошибку:

Соединение X11 отклонено из-за неправильной аутентификации.

Но другие работают: sux и su .

Конечно, я все еще смущен сообщением sux показывает:

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

  1. Почему он удаляет старые ключи? В чем же необходимость?

  2. И su и sux работают почти так же, как удаляют старые ключи, так и обе работают. Как и почему?

  3. И в чем причина того, что sudo su / sudo sux не работает?

Ответ (для sux ) указан в комментариях сценария. Это передача файлов-кубов X из ваших исходных разрешений пользователя в корневой каталог, чтобы позволить ему открывать X-дисплей, используя эти переданные разрешения.

Вот раздел, который стоит прочитать:

  # 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, eg 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