"$ sudo chmod -R 664 . "를 실행하면 영향을 받는 모든 디렉터리에 대한 액세스가 거부되는 이유는 무엇입니까?

"$ sudo chmod -R 664 . "를 실행하면 영향을 받는 모든 디렉터리에 대한 액세스가 거부되는 이유는 무엇입니까?

모든 파일에 대한 권한이 지저분한 프로젝트 폴더가 있습니다. 보안과 관련되지 않은 모든 문제를 해결했기 때문에 모든 것을 8진수 권한 777로 설정하는 나쁜 경향이 있었습니다. 그런 다음 FTP 업로드, 텍스트 편집기로 생성된 파일 등에는 자체 권한 세트가 있어 모든 것을 혼란스럽게 만듭니다. 나는 함께 힘을 모아 원래 의도된 대로 권한을 사용하기로 결정했습니다.

나는 664가 내 모든 파일과 폴더에 대한 좋은 기본값이라고 생각했으며 개인 파일에 대한 다른 사용자의 권한을 제거하고 실행 파일에 +x를 추가했습니다.

그러나 두 번째로 프로젝트 폴더를 664로 변경했습니다.

$ sudo chmod -R 664 .  
$ ls  
ls: 디렉토리를 열 수 없습니다.: 권한이 거부되었습니다.  

나에게는 말이되지 않습니다. 나는 읽기/쓰기 권한이 있고 프로젝트 폴더의 소유자입니다. 내 프로젝트 폴더의 가장 왼쪽 부분은 ls -l다음과 같습니다.

-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 5 코드몽키 코드몽키 ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 3 코드몽키 코드몽키 ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 4 코드몽키 코드몽키 ...
drw-rw-r-- 5 코드몽키 코드몽키 ...

나는 이것이 디렉토리에 대한 권한과 관련이 있다고 가정하지만,무엇?

답변1

*nix 디렉토리를 탐색하려면 실행 비트가 필요합니다. cd실행 권한이 없는 디렉토리에는 들어갈 수 없으며 이는 디렉토리 컨텍스트가 필요한 경우 명확하지 않은 방식으로 여러 유틸리티에 영향을 미칩니다. 고려하다:

$ cd /tmp
$ mkdir foo
$ echo baz > foo/bar
$ chmod a-x foo

# You can read the contents of the directory, but ls still complains. 
$ ls foo
ls: cannot access foo/bar: Permission denied
bar

# You can't read the file because you can't enter the directory.
$ cat foo/bar
cat: foo/bar: Permission denied

이 모든 이유는 stat()이 작동하는 방식 때문입니다. 발췌 man 2 stat:

파일 자체에는 권한이 필요하지 않지만 stat() 및 lstat()의 경우 파일로 연결되는 경로의 모든 디렉터리에 실행(검색) 권한이 필요합니다.

결론은 재귀가 chmod기대하는 것을 거의 수행하지 않으며 디렉터리 읽기 및 실행 권한을 혼란스럽게 하여 여러분과 같은 예상치 못한 결과를 초래할 수 있다는 것입니다. 최상의 결과를 얻으려면 항상 디렉터리 권한을 파일 권한과 별도로 처리하십시오.

답변2

디렉터리에 대한 실행 권한이 필요합니다.

고려하다

sudo find -type d -exec chmod +x {} +

업데이트: 이상해 보이는 실행 권한 사용에 대한 합리화는 다음과 같습니다.

Unix(따라서 Linux)는 거의 모든 것을 파일로 취급합니다. 이는 디스크 및 기타 다양한 장치로 확장됩니다. 여기에는 디렉토리도 포함됩니다.

기존 Unix 파일 시스템에는 파일에 적용되는 권한 집합이 있습니다. 따라서 Unix 설계자는 일반 데이터 파일이 아닌 "파일"에 적용될 때 수행할 각 권한 비트에 대해 유용한 것을 찾아야 했습니다.

디렉토리를 고려해 봅시다. 처음에는 누군가가 디렉토리에 액세스할 수 있는지 여부를 결정하기 위해 읽기 권한을 사용하는 것이 합리적으로 보입니다. 예를 들어 디렉토리에 있는 파일 목록과 크기 및 날짜 스탬프 등을 생성합니다.

그러나 일반 사용자가 /usr/local/bin에서 프로그램을 실행할 수 있기를 원하지만 거기에 무엇이 있는지 확인하기 위해 /usr/local을 뒤지는 것은 원하지 않는다고 가정해 보겠습니다. 읽기 권한만 있으면 이를 방지할 수 없습니다.

따라서 중복된 실행 권한은 쉘이 디렉토리를 "통과"할 수 있는지 여부를 제어하는 ​​데 사용되었습니다. 즉, 하위 디렉토리의 세부 정보를 부분적으로 찾고 읽는 데 필요한 더 이상 알아낼 수 없습니다. 경로의. 이를 통해 /usr/local/bin의 내용을 읽는 데 필요한 만큼만 /usr/local 디렉토리에 접근할 수 있습니다.

따라서 /usr/local의 +x는 "/usr/local/bin/foo"를 실행할 수 있음을 의미합니다. 그러나 /usr/local의 +r은 누가 소유하고 있는지, 어떤 권한을 포함하여 /usr/local에 있는 모든 것을 찾을 수 있음을 의미합니다. 각 파일의 크기, 크기 등

위의 내용은 막연한 기억과 추측에 근거한 것입니다. 그것은 정확히 사실이 아닐 수도 있지만 "실행"이 "횡단할 수 있음"을 의미하는 이유에 대한 합리적인 아이디어를 제공한다고 믿습니다.

관련 정보