디렉토리에서 setuid가 무시되는 이유는 무엇입니까?

Linux 시스템에서는 성공적으로 수행 할 수 chmod u+s $some_directory있지만 새 서브 디렉토리 및 파일의 소유권을 포함 디렉토리의 소유자 (및 서브 디렉토리 설정 u+s)로 강제하는 대신 시스템은 setuid 비트를 무시합니다. 서브 디렉토리 및 파일은 작성 프로세스의 UID를 계속 상속하며 서브 디렉토리는 기본적으로 설정되지 않습니다.

디렉토리에서 setuid가 무시되는 이유는 무엇이며 시스템에서이를 인식하도록하려면 어떻게해야합니까?

setuid와 setgid 비트는 완전히 다른 목적으로 개발되었다는 점을 상기하십시오. 다른 용도는 추가 기능 일뿐입니다.

이 비트는 실행 불가능한 일반 파일에서는 기능하지 않습니다. (보안 문제로 인해 일부 배포판의 쉘 스크립트도 있습니다.) 원래 디렉토리에는 기능이 없었습니다. 분명히 누군가는 디렉토리에서 사용하지 않는 setgid를 가져 와서 그룹 소유권의 일관성을 유지하기 위해 사용하는 것이 멋지겠다고 결정했습니다. 결국, 그룹 소유권을 가지고 놀고 있다면, 둘 이상의 사람이 파일을 사용하고 있기 때문이며, 주어진 디렉토리의 모든 파일이 누가 그것을 만들었든지 상관없이 같은 디렉토리에 속하는 것이 합리적 일 것입니다. 누군가 newgrp를 실행하는 것을 잊어 버린 번거 로움이 제거됩니다.

그렇다면 setuid와 파일 uid에 대해 동일한 기능을 구현하지 않는 이유는 무엇입니까? 음, uid는 gid보다 훨씬 더 기본입니다. 이것을 구현하면 파일은 종종 파일을 만든 사용자에게 속하지 않습니다! 아마도 사용자는 여전히 파일을 수정할 수 있지만 (umask가 제정신이라고 가정) 권한 비트를 변경할 수는 없습니다. 그 유틸리티를보기가 어렵습니다.

이 질문에 대한 답은 "파일 공짜"보안 문제에 달려 있다고 생각합니다. 이로 인해 대부분의 최신 유닉스 계열 OS는 "파일 공짜"를 허용하지 않습니다. "파일 공짜"는 수퍼 유저가 아닌 사용자가 파일의 소유권을 해당 사용자가 아닌 다른 사람으로 변경 한 경우입니다. 이 기능은 장난에 대한 많은 기회를 제공합니다.

파일 공짜가 허용되지 않으므로 다른 기능으로 동일한 기능을 수행하는 디렉토리의 setuid는 허용되지 않거나 설정되어 있으면 무시됩니다.

동작을 변경하려면 OS 라이브러리 및 유틸리티를 수정해야합니다.

그것을 구현하기위한 매우 좋은 사용 사례는 다음과 같습니다.

3 개의 보안 사이트가있는 다중 사이트 서버가 있다고 가정합니다. 서로 다른 사이트 관리자 각각에 대해 하나씩 3 개의 그룹이 작성되었습니다. 모든 사이트의 모든 파일은 아파치 사용자가 소유해야하므로 아파치에서 파일을 읽고 쓸 수 있습니다 (drupal / wordpress 등).

setuid이지만 디렉토리에 대한 setgid 비트처럼 작동하면 권한은 다음과 같습니다.

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

이 방법으로 각 관리자 그룹은 자신의 컨텐츠 만보고 액세스 할 수 있지만 웹 서버 사용자 아파치는 모든 컨텐츠를 제공 할 수 있으며 사용자는 업로드 된 파일의 소유권을 변경하는 것에 대해 걱정할 필요가 없습니다.

또 다른 사용 사례는 Anonymous ftp / http 또는 sftp / ssh 업로드입니다. 업로드 디렉토리의 그룹 및 GID는 루트이며 소유자 및 UID도 마찬가지입니다. 다른 권한은입니다 -wx. 이것은 모든 사람이 업로드 디렉토리에 대한 쓰기 권한을 허용하지만 일단 업로드되면 아무것도 읽을 수 없으며 루트는 새로 작성된 모든 파일을 소유합니다.

따라서 디렉토리의 UID 기능을 GID 비트와 일치시킬 수 있도록하는 두 가지 완벽하고 유효한 사용 사례가 있습니다.

스티븐 머큐리오

다른 사람들이 언급했듯이 표준 OS-X 파일 시스템에서 디렉토리의 setUID는 무시됩니다.이 문제를 해결하는 쉬운 방법은없는 것 같습니다. mount -o.... 또는 무엇을하지). 종종 매뉴얼 페이지는 문자 그대로 다음과 같은 OS-X 동작을 따르지 않습니다.

4000 (set-user-ID-on-execution bit) [...] set-user-id 비트 세트가있는 디렉토리는 디렉토리 소유자가 아닌 디렉토리 소유자가 해당 디렉토리에서 작성된 모든 파일 및 하위 디렉토리를 소유하게합니다. 만드는 과정의 uid [...]

또한 원래 소유권을 포기하지 않고도 동일한 효과를 얻을 수있는 가능성이 나열되어 있습니다. 리눅스는 비슷한 효과를 위해 '[g /] setfacls'를 사용합니다 (처음에는 권한이 보이지 않기 때문에 언젠가 성 가실 수 있습니다).

'유사한 효과를 얻는 방법'에 관해서는, 전체 매뉴얼 페이지를 읽고 바이올린을 사용하십시오.

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

당신은 통해 확인할 수 있습니다

ls -le

모두 괜찮아 보인다면. 추가 옵션에는 특정 위치에 규칙 삽입, 특정 규칙 제거 또는 교체가 포함됩니다. 여기서 주목할만한 두 가지 옵션은 " file_inherit및 directory_inherit"이며 규칙을 새 디렉토리 / 파일에 첨부 할 수 있습니다.

setUID를 좋아하지는 않지만 setGID는 단순히 'main'그룹을 설정해도 작동하지 않거나 클라이언트에 그룹 쓰기를 허용하지 않는 파일 마스크가있는 파일 서버에서 매우 편리합니다. 그것은 다음에 의해 해결 될 것입니다 :

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

글쎄요, 그것은 표준을 존중해야합니다. 나는 sftp-only를 가진 꽤 많은 시나리오에서 acl과 sshd가 수행하는 acl-mask-set 및 그 마스크에 해야하는 재설정으로 많은 문제를 해결할 것이라고 생각할 수 있습니다.

기본적으로 보안은 매우 유용하지만 옵션을 선택하지 않으면 winghtmare를 작성하는 것입니다.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

어느 쪽이든, 리눅스가 지금가는 것처럼, acl을 사용하여 그 문제를 해결하십시오.

http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories 에 따르면 setuid 비트는 UNIX 및 Linux 시스템의 디렉토리에서 무시됩니다. 그러나 FreeBSD에서 기대 한대로 작동하도록 만들 수 있습니다.