fakeroot 명령이 필요한 이유는 무엇입니까? 단순히 sudo 또는 su 명령을 사용할 수 없습니까?

맨 페이지에 다음 내용이 나와 있습니다.

fakeroot- 파일 조작

About.com 메시지 :

가짜 루트 제공 이 패키지는 dpkg-buildpackage -rfakeroot (예 : 패키지 빌드의 루트가 될 필요가 없음)와 같은 것을 활성화하기위한 것입니다. 이는 LD_PRELOAD에서 libfakeroot.so로, getuid, chown, chmod, mknod, stat, …, 따라서 가짜 루트 환경을 만듭니다. “이 중 하나도 이해하지 못합니다. fakeroot는 필요하지 않습니다!

제 질문은 어떤 sp 단순한 su 또는 sudo가 해결하지 못하는 것이 실질적인 목적입니까? 예를 들어, 우분투에 설치된 모든 패키지를 다시 포장하려면 다음 명령을 제공합니다.

$ fakeroot -u dpkg-repack `dpkg --get-selections | grep install | cut -f1` 

다음과 같이 fakeroot 대신 sudo 또는 su로 위 명령을 수행 할 수 있습니까?

$ sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1` 

수정 :

실행 중 :

$ sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1` 

이 오류를 표시합니다.

제어 디렉토리에 잘못된 권한 700 (> = 0755 및 < = 0775 여야 함)

이유가 있습니까?

코멘트

  • 보안상의 이유로 일반 사용자로 수행 할 수있는 모든 작업을 루트로 수행하지 않는 것이 좋습니다. sudo 또는 su. fakeroot에는 두 가지 용도가 있습니다. 1) 프로그램을 속여 당신이 실제로 루트 사용자라고 믿도록 만듭니다. 일부 잘못 작성된 독점 소프트웨어는 필요하지 않더라도 필요할 수 있습니다 (일반적으로 Windows 개발자가 Linux를 사용함). 2) 다른 방법으로는 할 수없는 ‘ 파일 모드 및 소유권 변경을 에뮬레이션 할 수 있습니다. 주로 올바른 권한이있는 tar 파일을 생성합니다. 예를 들어 소프트웨어를 패키징 할 때 유용합니다.
  • About.com에서 발췌 한 메모에 다음과 같이 요약되어 있습니다. 만약 당신이 ‘ 이 중 하나라도 이해하면 fakeroot가 필요하지 않습니다! fakeroot는 유용하지만 문자 그대로 필요하지 않습니다 ‘. 하지만 실제로 필요한 사람들은 사용 사례를 완전히 이해해야합니다.

답변

원격 서버에서 작업하는 개발자 / 패키지 관리자 등. 패키지의 내용을 업데이트하고 다시 빌드하고, kernel.org에서 커널을 다운로드 및 사용자 정의하고 빌드하는 등의 작업을 수행하려고합니다. 이러한 작업을 수행하는 동안 일부 단계에서는

권한 (UIDGID 0)은 다양한 이유로 (보안, 간과 된 권한 등). 그러나 원격 컴퓨터에서 작업하고 있기 때문에 root 권한을 얻을 수 없습니다 (다른 많은 사용자가 나와 동일한 문제를 가지고 있음). 이것이 정확히 fakeroot는 수행합니다. 필요한 환경에서 유효한 UIDGID 0 인 척합니다.

실제로는 실제 root 권한 (susudo).

댓글

  • 따라서 ‘ 시스템 설정 변경 ?? 우리가 실행할 명령은 ‘가 루트로 실행중인 것으로 ‘ 생각하고 원하는대로 수행합니다. 승리 ‘ 아니요?
  • @mrid 참고 ” 실제로는 실제 루트 권한을 얻지 못합니다. “. 따라서 anwser는 아닙니다

Answer

fakeroot와 실제 sudo / su의 차이점을 명확하게 보려면, 그냥하세요 :

$ fakeroot # echo "Wow I have root access" > root.tst # ls -l root.tst -rw-rw-r-- 1 root root 23 Oct 25 12:13 root.tst # ls -l /root ls: cannot open directory /root: Permission denied # exit $ ls -l root.tst -rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst 

당신이 fakeroot 셸에있는 한, 당신이 루트 인 것처럼 보입니다-아무것도하지 않는 한 정말 루트 권한이 필요합니다. 그리고 이것이 바로 모든 기계에서 의미있는 패키지를 만들기 위해 패키징 도구가 필요로하는 것입니다.

사실 패키징에 fakeroot를 사용할 때 달성하려는 것은 파일을 루트가 소유 한 것으로보기 위해 fakeroot에서 실행하는 도구를 만드는 것입니다. 그 이상도 그 이하도 아닙니다. 따라서 실제로 su 또는 sudo는 올바른 파일 소유권을 얻기 위해 작동하지 않습니다.

댓글

  • 위조가 위험하지 않나요? suid 비트와 rx perm을 사용하여 파일을 생성하면 루트 소유의 파일이 생성되고 누구나 실행할 수있는 루트로 파일이 생성됩니다! 아니면 suid 비트 설정이 작동하지 않을까요?
  • 좋지 않습니다. 나는 이것을 직접 시도했다. fakeroot의 주된 이유는 실제로 루트가되지 않고 root : root 소유권을 빌드 된 패키지로 가져 오는 것입니다. 그래도 설치된 패키지에는 적절한 perms가 있습니다.
  • @ ntzrmtthihu777 ‘의 댓글을 읽기 전까지는 매우 혼란 스러웠습니다!
  • 죄송합니다. 설명을 이해하지 못합니다. ‘ 루트가 아니어도 ‘ 불평하지 않도록 도구를 패치하지 않겠습니까? 관련 질문으로 : 결국 fakeroot에서 만든 파일은 루트가 실제로 소유하지 않습니다. ‘이 .deb 파일을 설치할 때 내 모든 /usr를 의미하지는 않습니다. 파일은 fakeroot?
  • @ JohannesSchaub-litb라고 부르는 사용자가 소유합니다. ‘ 요점입니다. 파일은 루트가 소유하지 않지만 fakeroot 셸 내부에서는 같아 보입니다 . .deb 패키지가이 셸 내에서 생성되면 파일 소유자가 파일 시스템에서 읽혀집니다 (fakeroot가 가로 채서 root를 반환 함). 패키지에 저장됩니다. 패키지를 설치할 때 패키지가 파일을 루트가 소유해야 함을 나타내므로 dpkg는 루트 액세스가 필요합니다.

Answer

답이 이해하기 어렵고 (이 댓글 을 통해 이해하게 되었기 때문에) 저는 “m 더 나은 설명을 드릴 것입니다.

1. fakeroot에서 일어나는 일

자신의 사용자에게 일어나는 일보다 더 이상은 없습니다. 당연히 더 이상은 없습니다. fakeroot (호출 될 때 sudo와 같은 새 셸을 제공함), 권한이 필요한 작업을 수행하는 척하고 종료하면 아무 일도 일어나지 않습니다.

생각하면 시간 낭비입니다. 왜 실제로 일어나지 않을 일을하겠습니까? 당신은 아무것도하지 않았을 수도 있고 아무런 차이도 없었을 것입니다. 그 흔적이 전혀 없기 때문입니다.

잠깐만 …

2. The trace of fakeroot

있을 수 있습니다 fakeroot. MortenSickel의 답변 은 매우 훌륭하고 찬성 할 만합니다.

$ fakeroot # echo "Wow I have root access" > root.tst # ls -l root.tst -rw-rw-r-- 1 root root 23 Oct 25 12:13 root.tst # ls -l /root ls: cannot open directory /root: Permission denied # exit $ ls -l root.tst -rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst 

첫눈에 보면 다음과 같이 보입니다. fakeroot를 사용한 것은 총 시간 낭비였습니다. 결국 fakeroot를 사용하지 않았다면 동일한 결과를 얻었을 것입니다.

여기에서 미묘한 점은 다음과 같습니다.

$ cat root.tst Wow I have root access 

파일의 내용이 여전히 루트임을 기억한다는 의미입니다. fakeroot를 사용하지 않으면 동일한 결과가 생성되었다고 말할 수 있습니다. 맞습니다.이 예는 너무 간단합니다.

다른 예를 들어 보겠습니다.

$ fakeroot # touch x # touch y # chown myuser:myuser x # ls -l > listing # exit $ ls -l total 4 -rw-rw-r-- 1 myuser myuser 152 Jan 7 21:39 listing -rw-rw-r-- 1 myuser myuser 0 Jan 7 21:39 x -rw-rw-r-- 1 myuser myuser 0 Jan 7 21:39 y $ cat listing total 0 -rw-rw-r-- 1 root root 0 Jan 7 21:39 listing -rw-rw-r-- 1 myuser myuser 0 Jan 7 21:39 x -rw-rw-r-- 1 root root 0 Jan 7 21:39 y 

어떤 일이 일어 났는지 살펴 보겠습니다. 나는 완전히 비효율적 인 root 인 척하여 xy를 만들었습니다. xmyuser에 속한 척하고 y는 . 실제로 둘 다 myuser에 속하지만 (끝에서 볼 수 있듯이) 저는 그저 그런 것처럼 인척 했습니다.

그런 다음 목록을 만들고 상상력을 파일에 저장했습니다. 나중에 파일을 다시 살펴보면 누가 파일을 소유해야한다고 생각했는지 알 수 있습니다. 다시 말하지만, 그들은 실제로 내가 상상 한 사람들의 소유가 아니라 단순히 상상했습니다.

3. 그래서 … 왜 다시 원하십니까?

그 목록을 만들기 위해 루트로 속일 필요는 없다고 말할 수 있습니다. 단순히 목록을 만든 다음이를 반영하도록 편집 할 수 있습니다. 내 상상력입니다. 당신이 맞습니다. fakeroot가 필요하지 않았습니다. 사실, fakeroot가 실제로 아무것도하지 않는다는 것을 알기 때문에 이전에는 없었던 능력을 얻을 수 없었을 것입니다.

하지만 , 이것이 fakeroot에 관한 것이므로 목록을 편집하는 것은 간단하지 않을 수 있습니다.시스템에 설치할 수있는 패키지와 마찬가지로 tar ed, gzip ed, xz ed, bzip2 ed 또는 파일을 함께 유지하고 권한 및 소유자를 기억하는 기타 형식. 압축 파일을 쉽게 수정하고 파일 소유권을 편집 할 수 있습니까? 나는 당신에 대해 모르지만 방법을 생각할 수는 없습니다.

모든 것이 압축되면 압축 된 파일을 수정하고 소유권과 권한을 프로그래밍 방식으로 편집하는 도구가 만들어 질 수 있을까요? ? 네 가능합니다. 따라서 압축하기 전에 소유권을 위조하거나 나중에 변경할 수 있습니다. 데비안 사람들은 전자가 더 쉽다고 결정했습니다.

4. sudo를 사용하지 않는 이유는 무엇입니까?

우선, 소프트웨어를 빌드하는 데 루트 권한이 필요하지 않으며 압축하는 데 루트 권한이 필요하지 않습니다. 그래서 만약 당신이 그것을 필요로하지 않는다면, 당신은 정말로 그 권한을 얻는 것을 생각하기 위해 Windows 사용자가되어야합니다. 하지만 비꼬는 것 외에는 루트 암호조차 없을 수도 있습니다.

게다가, 루트 권한이 있다고 가정 해 보겠습니다. 그리고 파일에 대한 읽기 액세스 권한 만있는 척하고 싶다고 가정 해 보겠습니다. 뿌리. 따라서 sudo 실제로 파일 소유자와 권한을 root로 변경하고 루트 셸에서 나와 모든 것을 패키징합니다. 이제 루트 액세스 권한이 없기 때문에 더 이상 파일을 읽을 수 없기 때문에 실패합니다. 따라서 sudo 패키지를 압축하고 루트로 빌드해야합니다. 실제로는 이렇게해야합니다. 모든 것이 루트로.

이것은 Bad TM 입니다.

패키저는 루트 권한이 필요하지 않으며이를 가져 와서는 안됩니다. 패키지를 설치하는 경우 일부 파일 (A)을 루트로 설치해야 할 수 있으며 여기에서 루트 권한이 필요합니다. fakeroot의 모든 작업은이를 가능하게하는 것입니다. 패키지 프로그램은 아카이버에 대해 루트가 소유 한 것으로 A를 나열 할 수 있으므로 사용자가 패키지의 압축을 풀 때 아카이버는 루트 권한을 요구하고 는 루트 소유입니다.

댓글

  • 훌륭한 글로 명확합니다.
  • So either you could fake the ownerships before compressing, or change them after. Debian people decided the former is easier. ‘ 이후에 수정하지 않는 이유는 무엇입니까? ‘

를 계속 생각하면서 도움이되었습니다. li>

  • 감사합니다. @Morten ‘의 답변
  • Answer

    AFAIK, fakeroot는 파일 조작에 대한 루트 권한이있는 것처럼 보이는 환경에서 명령을 실행합니다. 이것은 사용자가 루트 권한 / 소유권을 가진 파일이있는 아카이브 (tar, ar, .deb 등)를 만들 수 있도록하는 데 유용합니다. fakeroot가 없으면 루트 권한이 있어야 올바른 권한과 소유권을 가진 아카이브의 구성 파일을 만든 다음 압축하거나 아카이버를 사용하지 않고 아카이브를 직접 구성해야합니다.

    fakeroot는 파일 조작 라이브러리 함수 (chmod (), stat () 등)를 사용자가 실제로 루트 였다면 실제 라이브러리 함수가 가질 수있는 효과를 시뮬레이션하는 것으로 대체하여 작동합니다.

    시놉시스 :

     fakeroot [-l|--lib library] [--faked faked-binary] [--] [command] 

    여기에서 자세한 내용을 확인하세요. fakeroot

    댓글

    • @MaskTheSmokin : 따라서 fakeroot는 파일 조작 작업에 대해서만 슈퍼 유저 권한을 제공합니다.
    • 슈퍼 유저 파워는 가짜 일뿐입니다. 실행중인 프로그램은 루트 권한이 있다고 생각하지만 실제로는 여전히 사용자의 일반 권한을 사용합니다 ‘.
    • the program running in it thinks it has root privileges와 루트 권한이있는 프로그램의 차이점은 무엇입니까? rm -rf / 및 프로그램을 수행 할 수 있다면 루트 권한이있는 것으로 생각하고 실행하면 …
    • @userunknown rm ‘는 사용자에게 충분한 권한이 있는지 확인하지만 커널 자체는 ‘이 작업을 허용하지 않습니다. ; unlink 시스템 호출이 실패합니다. 권한을 처리하는 것은 애플리케이션 단독으로 ‘ 또는 사용자가 ‘
      자체 애플리케이션을 작성할 수 있습니다. id = “02ddd2c2dd”>

      권한을 확인하지 않고 원하는대로 수행합니다.

    • fakeroot의 필요성을 설명하는 예는 환상적입니다. fakeroot의 사용은 볼 수 있지만 ‘ 사람이 루트 권한을 해결하지 못하는 이유를 ‘ 알 수 없습니다. ‘는 속이기 쉽습니다.

    Answer

    나는 이것을 패키지 작성 스크립트에 사용했습니다. 스크립트에는 루트 수준 액세스 권한이 있지만 스크립트는 여전히 루트에 속한 파일이 포함 된 tar 파일을 생성해야했습니다. 가장 간단한 방법은 fakeroot 아래에서 패키지 빌드 스크립트를 실행하는 것이 었는데, 이는 아카이버가 파일은 루트에 속하며 아카이브 내부에 압축됩니다. 이렇게하면 패키지가 대상 시스템 (모두 다른 시스템에 있음)에 압축 해제 될 때 파일이 “이상하거나 존재하지 않는 사용자의 것이 아닙니다. / p>

    내가 본 유일한 장소는 임베디드 시스템의 rootfs, tar.gz 아카이브, rpm 패키지, .deb 패키지 등 일종의 아카이브를 구축하는 곳이었습니다.

    코멘트

    • fakeroot는 버그가있는 패키징 소프트웨어를위한 해결 도구입니다. 루트 권한이 필요하지 않습니다. 이러한 패키지, b ut, ‘ 선택의 여지가없는 미리 파일 시스템에 직접 설정하는 것 이외의 다른 방법으로 파일 권한을 지정할 수 없기 때문에

    답변

    일반적인 용도 중 하나는 실패한 바이너리가 실제로 액세스하려는 파일을 찾는 것입니다. 즉, 하드 코딩 된 경로와 부적절한 예외 처리로 인해 발생하는 버그를 찾아 수정하거나 해결합니다.

    답변

    다음 작업을 수행 할 수 있습니다. 실제로 루트 권한없이 fakeroot를 사용합니다. su 및 / 또는 sudo가있는 경우 간단한 rm -rf /,하지만 fakeroot를 사용하면 최대 홈 디렉토리를 삭제할 수 있습니다.

    댓글

    • 그렇지 않습니다 ‘ fakeroot의 필요성을 설명하지 않습니다. 홈 디렉토리를 직접 삭제할 수 있습니다.

    답변

    간단한 답변 :

    su 및 sudo는 명령을 루트로 실행합니다. fakeroot는 부분적인 샌드 박스 배열 외에는 그렇지 않습니다.

    답글 남기기

    이메일 주소를 발행하지 않을 것입니다. 필수 항목은 *(으)로 표시합니다