☰

sudo -i와 sudo su의 차이점 [중복]

tag-icon • tag-icon sudo command su
sudo -i와 sudo su의 차이점 [중복]

sudo -i이들그리고 그리고 의 차이점은 무엇인가요 sudo su?

답변1

매뉴얼 페이지 설명을 기반으로 다음을 가정합니다 su.sudo

  1. 로그인 셸을 나타내 므로 이는 또는 sudo -iu <user>와 동일합니다 .su - <user>su -l <user>
  2. 매개변수를 사용 하지 않으면 su유효 사용자 ID가 변경되지만 여전히 원래 <user>환경을 사용하고 who am i있으며 여전히 <user>.

sudo 매뉴얼 페이지에서 발췌

-i [command]
        The -i (simulate initial login) option runs the shell specified in
        the passwd(5) entry of the target user as a login shell.  This means
        that login-specific resource files such as .profile or .login will 
        be read by the shell.  If a command is specified, it is passed to 
        the shell for execution.  Otherwise, an interactive shell is 
        executed.  sudo attempts to change to that user's home directory 
        before running the shell.  It also initializes the environment, 
        leaving DISPLAY and TERM unchanged, setting HOME, MAIL, SHELL, 
        USER, LOGNAME, and PATH, as well as the contents of 
        /etc/environment on Linux and AIX systems.  All other environment 
        variables are removed.

예

UID 500을 가진 사용자 계정이 있습니다 saml.

$ egrep "Uid|Gid" /proc/$$/task/$$/status
Uid:    500 500 500 500
Gid:    501 501 501 501

위 출력에서 ​​첫 번째 열은 실제 UID(uid)이고 두 번째 열은 유효 UID(euid)입니다.

(su)를 통해 루트가 됨

$ su

이제 저는 루트이지만 여전히 환경을 유지하고 있으며 실제 UID도 그대로 남아 있습니다 500. 내 euid는 이제 0(루트)입니다.

$ egrep "Uid|Gid" /proc/$(pgrep su -n)/task/$(pgrep su -n)/status
Uid:    500 0   0   0
Gid:    501 501 501 501

하지만 내 환경은 여전히 saml​​똑같다. 환경변수 중 하나입니다 $LOGNAME.

$ env | grep LOGNAME
LOGNAME=saml

(su -) 또는 (sudo -i)를 통해 루트가 됩니다.

$ su -

내 유효 UID를 새 사용자에게 사용하거나 변경할 su -뿐만 sudo -i아니라 로그인한 것처럼 파일을 가져오고 이제 내 환경은 마치 직접 로그인한 것과 동일해집니다.

$ egrep "Uid|Gid" /proc/$(pgrep su -n)/task/$(pgrep su -n)/status
Uid:    500 0   0   0
Gid:    501 501 501 501

하지만 내 환경은 현재입니다 root. 이제 동일한 변수를 $LOGNAME설정하는 데 사용됩니다 root.

$ env | grep LOGNAME
LOGNAME=root

그렇다면 차이점은 무엇입니까?

자, 위의 방법을 시도해 sudo -i보고 알아봅시다.

$ sudo -i

이제 동일한 정보를 살펴보겠습니다.

$ egrep "Uid|Gid" /proc/$(pgrep su -n)/task/$(pgrep su -n)/status
Uid:    0   0   0   0
Gid:    501 501 501 501

root그런데 중요한 점은 이 방법을 사용하면 나의 유효 ID와 실제 ID가 모두 0()이라는 점입니다. 환경 변수 $LOGNAME는 root.

$ env | grep LOGNAME
LOGNAME=root

환경 비교

이 3가지 방법으로 행 수를 세면 추가 정보를 얻을 수 있습니다.

$ env > /tmp/<method used to become root>

이제 다음 3개의 파일이 남았습니다.

  • -rw-r--r-- 루트 루트 1개 1999년 11월 2일 06:43 sudo_root.txt
  • -rw-r--r-- 루트 1개 1970년 11월 2일 06:44 sudash_root.txt
  • -rw-r--r-- 1 루트 루트 4859 11월 2일 06:44 su_root.txt

우리는 이미 simple.environment 만을 볼 수 있습니다 su. 다른 사이즈에 비해 2배 이상 큽니다.

한 줄당 줄 수:

$ wc -l su*
  28 sudash_root.txt
  32 sudo_root.txt
  92 su_root.txt

실제로 파일을 더 자세히 살펴볼 필요는 없습니다 su_root.txt. 이 파일에는 명령을 실행하기 위한 대부분의 사용자 환경이 포함되어 있습니다 su. 그럼 나머지 2개의 파일을 살펴보겠습니다.

몇 가지 외관상의 변수(예: 약간 다른 변수)를 제외하면 $LANG실제로는 동일합니다. 목록에서 가장 끔찍한 증거는 $PATH.

스도

 PATH=/usr/lib64/ccache:/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/brlcad/bin:/root/bin

수-

PATH=/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/brlcad/bin:/root/bin

보시다시피 의심스러운 경로를 제거하여 추가 보호 기능을 제공하지만 GUI를 다른 위치에 표시하는 경우 에도 sudo -i그대로 유지합니다 .$DISPLAY$TERM

테이크아웃?

  1. 가장 큰 장점은 루트가 되는 방법은 sudo -i자신의 비밀번호를 사용하여 루트의 비밀번호를 공개할 필요가 없다는 점에서 다른 방법에 비해 이점이 있다는 것입니다.
  2. 언제 가 되는지에 대한 로그가 있는데 root, 신비롭게 누군가 root가 지나가 su거나 가 됩니다 su -.
  3. sudo -i귀하 와 를 su보호하므로 이들 중 하나보다 더 나은 사용자 경험을 제공합니다 .$DISPLAY$TERM
  4. sudo -iroot사용자가 특정 환경을 제한하여 시스템을 일부 보호합니다.

어때요 sudo su? 이 문제에 대해 아직 논의도 안 해보셨나요?

OP가 이에 대해 질문했지만 IMO라는 질문을 혼란스럽게 할 수 있기 때문에 의도적으로 토론에 포함시키는 것을 피했습니다. sudo su이 명령을 실행하면 sudo명령의 효과가 가려지고 su일반 환경에서 얻은 환경의 대부분이 su손실됩니다. Sudo는 해당 작업을 수행하고 제한적이고 보호된 환경을 제공 sudo su합니다 sudo -i.

예

이는 환경이 덤프된 결과입니다 sudo su.

ls -l /tmp/sudosu_root.txt
-rw-r--r-- 1 root root 1933 Nov  2 14:48 /tmp/sudosu_root.txt

행 수는 다음과 같습니다.

$ wc -l /tmp/sudosu_root.txt 
31 /tmp/sudosu_root.txt

sudo su -a 와 a 사이에 차이가 있는 유일한 변수는 다음과 같습니다 sudo -i.

$ sdiff /tmp/sudosu_root.txt /tmp/sudo_root.txt  | grep ' |'
USERNAME=saml                             | USERNAME=root
PATH=/usr/lib64/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/brl | PATH=/usr/lib64/ccache:/usr/local/sbin:/sbin:/bin:/usr/sbin:/
MAIL=/var/spool/mail/saml                 | MAIL=/var/spool/mail/root
PWD=/home/saml/tst                        | PWD=/root
SUDO_COMMAND=/bin/su                      | SUDO_COMMAND=/bin/bash
XAUTHORITY=/root/.xauthYFtlL3             | XAUTHORITY=/var/run/gdm/auth-for-saml-iZePuv/datab

보시다시피, 그들 사이에는 실제로 큰 차이가 없습니다. 약간 다른 $PATH, $SUDO_COMMAND, 의 차이점만 $MAIL있습니다 .$USERNAME

인용하다

답변2

@slm이 질문을 오해한 것 같아서 다른 답변을 제공하세요.

그는 요점을 맞추었습니다. 하나는 로그인 쉘이고 다른 하나는 그렇지 않습니다.
실행되면 sudo -i쉘은 로그인 쉘이 되므로, ~/.profile로그인이 아닌 쉘에서는 ~/.bashrc.

sudosu(예: ) 과 연결되면 sudo su및 둘 다 로그인 쉘을 sudo호출 하지 않습니다. 사용할 su때 동등한 것은 입니다 .sudo -isusudo su -l

나는 개인적으로 sudo su이것이 "고양이의 쓸모없는 사용"예와 비슷하다고 생각합니다. 를 사용하여 동일한 동작을 얻을 수 있습니다 sudo -s.

기본적으로 sudo를 통해 루트 쉘을 호출하는 5가지 일반적인 방법이 있습니다.

  • sudo su

    • 비로그인 쉘
    • HOME로 설정/root
    • 가지치기 환경

  • sudo -i

    • 로그인 쉘
    • HOME로 설정/root
    • 가지치기 환경

  • sudo su -l

    • 로그인 쉘
    • HOME로 설정/root
    • 가지치기 환경

    쉘을 호출할 때 이는 다음과 같습니다.sudo -i

  • sudo -s

    • 비로그인 쉘
    • HOME로 설정/root
    • 가지치기 환경

    쉘을 호출할 때 이는 다음과 같습니다.sudo su

  • sudo -Es

    • 비로그인 쉘
    • HOME내버려둬
    • 환경에 영향 없음( $PATHiirc 제외 $LD_LIBRARY_PATH)

이 규칙은 쉘을 얻기 위해 사용할 때만 적용됩니다. sudo -s somecommand와 사이에는 차이가 있습니다 sudo su -c somecommand.

답변3

두 번째 명령은 현재 디렉터리(pwd)를 유지하지만 첫 번째 명령은 사용자를 루트의 홈 디렉터리에 배치합니다.

관련 정보