☰

X11 인증은 "sudo sux/sudo su"에서는 작동하지 않지만 "sux/su"에서는 작동합니다. 왜?

tag-icon • tag-icon x11 su xauth
X11 인증은 "sudo sux/sudo su"에서는 작동하지 않지만 "sux/su"에서는 작동합니다. 왜?

su - usersux가 필요 없이 다른 사용자를 위해 실행하여 X11에 액세스 할 수 있는 vnc 세션이 있습니다 .

sudo sux - user또한 user 를 사용하거나 전환하려고 하면 sudo su - userX11에 액세스할 수 없고 다음 오류가 발생합니다.

인증 오류로 인해 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작동하지 않습니까?

답변1

답( 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, 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

관련 정보