rm이 다른 사용자의 소유권으로 파일을 삭제할 수있는 이유는 무엇입니까?

게시물에서 rm은 왜 읽기 전용 파일을 제거 할 수 있습니까? rm파일을 제거하려면 디렉토리에 대한 쓰기 권한이 필요 하다는 것을 이해 합니다. 그러나 소유자와 그룹이 다른 파일을 쉽게 삭제할 수있는 동작을 요약하기가 어렵습니다.

나는 다음을 시도했다

mtk : 내 사용자 이름
abc : 새로운 사용자 생성

$ ls -l file
-rw-rw-r-- 1 mtk mtk       0 Aug 31 15:40 file
$ sudo chown abc file
$ sudo chgrp abc file
$ ls -l file
-rw-rw-r-- 1 abc abc       0 Aug 31 15:40 file
$ rm file
$ ls -l file
<deleted>

나는 이것이 허용되어서는 안된다고 생각했다. 사용자는 자신이 소유 한 파일 만 삭제할 수 있습니까? 누군가 이것이 왜 허용되는지 밝힐 수 있습니까? 그리고 이것을 피하는 방법은 무엇입니까? 놀랍게도 파일 삭제를 허용하지 않기 위해 부모 디렉토리의 쓰기 권한을 제한하는 것만 생각할 수 있습니다.

이것이 허용되는 이유는 실제로 파일을 제거하는 것과 관련이 있습니다. 개념적으로 rm작업은 디렉토리에서 이름 항목을 제거하는 것입니다. 파일이 파일의 유일한 이름이고 파일이 차지하는 inode 및 공간을 그 시점에서 복구 할 수있는 경우 파일에 도달 할 수 없다는 사실은 거의 부수적입니다. rm명령이 호출 하는 시스템 호출의 이름은 unlink이 사실을 암시합니다.

디렉토리에서 이름 항목을 제거하는 것은 기본적 으로 해당 디렉토리 에서 수행되는 작업 이므로 해당 디렉토리는 쓰기 권한이 있어야합니다.

다음과 같은 시나리오가 더 편안하게 느껴질 수 있습니까? 디렉토리가 있다고 가정하십시오.

/home/me    # owned and writable only by me
/home/you   # owned and writable only by you

그리고 내가 소유하고 두 개의 하드 링크가있는 파일이 있습니다.

/home/me/myfile
/home/you/myfile

그 하드 링크 /home/you/myfile가 처음에 어떻게 도착 했는지 신경 쓰지 마십시오 . 어쩌면 root거기에 넣을 수도 있습니다.

이 예의 아이디어는 하드 링크를 제거 할 수 있어야한다는 것 /home/you/myfile입니다. 결국, 그것은 어지럽히고있어 사용자의 디렉토리. 내부에 존재하는 것과 존재하지 않는 것을 제어 할 수 있어야합니다 /home/you. 그리고 제거 할 때 /home/you/myfile실제로 파일을 삭제하지 않았 음을 알 수 있습니다. 링크를 하나만 제거했습니다.

끈적 끈적한 비트가 파일을 (로 나타 포함하는 디렉토리에 설정되어있는 경우 참고 t에 ls), 당신은 않습니다 (당신이 디렉토리를 소유하지 않은 경우)을 삭제하도록 허용하기 위해 파일의 소유자 여야합니다. 스티커 비트는 일반적으로 설정되어 /tmp있습니다.

파일을 제거하려면 파일이있는 디렉토리에 쓸 수 있어야합니다.

이 방법이 마음에 들지 않으면 chmod +t dir최근 OS의 절반 정도 인 경우 "스티커"비트를 설정할 수 있습니다 (이 기능은 1986 년경 SunOS에서 소개되었습니다).

좀 더 세분화되고 싶다면 ZFS와 같은 최신 ACL 구현을 가진 파일 시스템이 필요합니다. NTFS 기반의 표준 NFSv4 ACL에는 사용자 당 파일 별 삭제 권한 지원 및 디렉토리에 대한 "delete_child"권한이 포함됩니다.

논리는 집의 논리와 비슷합니다. 소유자 또는 임차인은 누가 손님을 소유하든 관계없이 어떤 손님을 버릴지를 결정합니다. 또한 다른 집에서 환영받는 퇴거 손님 (다른 사람의 디렉토리에 다른 하드 링크가 있음)은 외부에서 얼지 않습니다.