최근에 우리는 많은 사용자가 사용하는 Red Hat Linux 상자에서 문제에 직면했습니다. /usr/bin/sudo바이너리가 접착력을 잃었습니다. 루트 사용자가 문제를 해결할 때까지 작업이 차단됩니다( sudo배포 및 테스트가 필요함 ).
이 실패의 원인은 ... $HOME/bin/s가 가리키는 심볼릭 링크 입니다 /usr/bin/sudo. 나는 bash 별칭이 하나 더 나쁘고 심볼릭 링크가 모든 쉘에서 작동하는 더 간단한 솔루션이라고 생각했기 때문에 $HOME/bin/s에 대한 지점을 만든 다음 "만일의 경우" Call up 에 복사 /usr/bin/sudo했습니다 . 결과는 필수 4111 대신 0755 권한이었습니다. 이제 문제가 해결되었으며 루트가 로그인되었으며 sudo가 복원되었습니다.$HOME/bin$HOMEsudo chmod 755 $HOME/bin/*/usr/bin/sudo
man chmod(레드햇, 우분투):
chmod never changes the permissions of symbolic links; the chmod system
call cannot change their permissions. This is not a problem since the
permissions of symbolic links are never used. However, for each sym-
bolic link listed on the command line, chmod changes the permissions of
the pointed-to file.
내 질문은: 바이너리에 대한 심볼릭 링크를 생성해서는 안 되기 때문에 이것이 내 잘못입니까, 아니면 동작이 chmod잘못되어 심볼릭 링크가 가리키는 파일의 권한을 변경해서는 안 됩니까? 왜 이런 일이 발생합니까 chmod? 이게 말이 되나요?
답변1
바이너리에 대한 심볼릭 링크를 만들어도 괜찮습니다. /bin그러면 /usr/bin거의 확실히 많은 별칭을 찾을 수 있습니다. 여기서 문제는 sudo결과를 완전히 이해하지 않고 사용한다는 것입니다. 다행히 영구적인 손상은 발생하지 않았으며 중요한 교훈을 얻었습니다. 실행 가능한지 확인하고 싶을 때 사용하거나 a+x교체 하세요. u+x~처럼우서 라고, 어쨌든 별칭을 사용하는 것이 더 나을 것입니다.
매뉴얼 페이지 자체에서 이것이 수행되는 이유를 설명합니다. 심볼릭 링크의 권한은 중요하지 않으며 해당 링크가 해결하는 파일의 권한만 중요합니다. 종종 사용자는 링크가 가리키는 파일의 속성을 변경하고 싶어합니다.
또한 방금 chmod()Linux 및 BSD 시스템 호출 매뉴얼 페이지를 확인했습니다. 둘 다 심볼릭 링크 루프에 대한 오류를 반환합니다. 즉, 링크 권한이 아닌 파일 권한을 변경하는 동작이 커널 수준에서 결정되고 적용됩니다.
답변2
동의합니다. 심볼릭 링크를 심볼릭 링크로 생각하면 별 의미가 없습니다.
그러나 심볼릭 링크를 하드 링크로 생각하면 더 의미가 있습니다.
첫 번째 줄은 man 7 symlink정확히 다음과 같이 말합니다.
Symbolic links are files that act as pointers to other files. To understand their behavior, you must first understand how hard links work. A hard link to a file is indistinguishable from the original file because it is a reference to the object underlying the original filename. [...] Changes to a file are independent of the name used to reference the file.
따라서 하드 링크를 사용하면 파일의 권한을 어떤 이름으로든 변경하면 모든 이름의 기본 권한이 변경됩니다.
대부분의 도구는 심볼릭 링크를 따라가려고 시도하므로 실제로 하드 링크인 것처럼 가장할 수 있습니다.
Except as noted below, commands follow symbolic links named as command-line arguments. The mv(1) and rm(1) commands do not follow symbolic links named as arguments, but respectively attempt to rename and delete them. Commands traversing a file tree [...]
바이너리 파일에 대한 심볼릭 링크(또는 하드 링크)를 생성하는 것이 유용할 때도 있지만 방금 발견한 것처럼 문제를 일으킬 수 있는 몇 가지 극단적인 경우가 생성됩니다.
즉, 여기서 더 큰 문제는 sudo필요하지 않을 때 사용하는 것이라고 생각합니다.
다른 사용자가 귀하의 것에 대한 읽기 액세스 권한을 갖고 있어야 한다면 ~/bin이는 sudo전혀 필요하지 않습니다.
또는 액세스 권한이 없는 경우 액세스 권한을 부여하거나(예: 사용 chmod g+rx $HOME/bin) 타르볼을 제공할 수 있습니다.
sudo여전히 사용하는 것이 좋은 생각이라고 생각한다면 다음과 같은 몇 가지 대안이 있습니다.
sudo chown -h $USER $HOME/bin/*
chmod 755 $HOME/bin/*
-hchown심볼릭 링크를 따르지 말라고 지시
chmod -R 755 $HOME/bin/*
-R위의 man 7 symlink.
sudo find $HOME/bin/ -type f -exec chmod 755 {} +
-type f(이 경우) 심볼릭 링크에서 exec 명령을 실행 find하지 않도록 지시합니다 .chmod
# as user 2
cd ~user2/bin
sudo tar -C ~user1/bin -cf - . | tar -xf -
루트로 실행하면 tar -cf모든 파일을 볼 수 있지만 tar -xfuser2로 실행하면 추출된 파일이 user2의 소유가 됩니다.
답변3
미켈이미 말했지만 그의 답변에 묻혀 있습니다. 따라서 실제로 잘못되고 있는 것은
sudo chmod 755 $HOME/bin/* # <<<< highly suspicious!
홈 디렉토리의 파일을 조작하려면 슈퍼유저 권한이 필요하다는 것이 다소 이상합니다. 그 사람이 자신의 홈 디렉토리에서 어떤 작업을 수행할 수 있는 권한이 없다는 것을 알게 되면 맹목적으로 sudo를 실행하기보다는 상황을 조사해야 합니다. 반복하자면:sudo를 맹목적으로 실행하지 마세요. 그 사람이 도망가면 /home/guy/bin/s': Operation not allowed`라는 chmod 755 $HOME/bin/*오류 메시지가 표시됩니다 .chmod: changing permissions of
그런데 별칭을 만드는 것은 권장하지 않습니다. (이렇게 해야 한다면 심볼릭 링크 대신 쉘 별칭을 사용하는 것이 좋습니다. 이 이름은 스크립트에서 사용할 수 없다는 의미입니다 s. ) 이는 무해한 작업이 아니며 런타임에 세 개의 추가 문자를 입력할 수 있습니다. 단일 문자 별칭을 지정하면 철자가 틀릴 위험이 높아집니다.sudosudo
다소 놀랍게도 chmod대부분의 메타데이터 작업은 기호 링크 대상에서 작동하는 반면 대부분의 메타데이터 작업은 링크 자체에서 작동합니다. 그러나 심볼릭 링크에는 유용한 권한이 없습니다. 심볼릭 링크는 작성되거나(생성 및 덮어쓰기만) 실행되지 않으며 대상을 숨기는 의미가 거의 없습니다. Unix 변형은 chmod기호 링크(일부 시스템에서는 지원되지 않음), 해당 대상에 영향을 미치는지, 아니면 둘 다에도 영향을 미치는지 여부가 다릅니다. Linux에서는 chmod대상에 영향을 줍니다.
답변4
별칭을 만드는 것과 파일에 대한 기호 링크를 만드는 것은 모두 유효합니다(일반적으로 별칭이 선호되지만). 나는 이 상황에 대해 "잘못"된 것이 없다고 생각합니다. 이것이 동작 chmod이므로 이제 심볼릭 링크 파일 작업 방법(변경되지 않음)을 알게 되었으며 chmod앞으로는 이 작업을 피할 수 있습니다. 이런 일이 다시 발생하면 해결 방법을 알고 계실 것입니다.