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の仕事はディレクトリから名前エントリを削除することです。ファイルがファイルの唯一の名前である場合、ファイルに到達できなくなる可能性があり、そのため、その時点でファイルが占有しているiノードとスペースを回復できるという事実は、ほとんど偶発的なものです。rmコマンドが呼び出すシステムコールの名前は、unlinkこの事実を示唆しています。

また、ディレクトリから名前エントリを削除することは、基本的にそのディレクトリに対する操作であるため、そのディレクトリは書き込み権限を持っている必要があります。

次のシナリオは、より快適に感じるかもしれませんか？ディレクトリがあるとします：

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

そして、私が所有し、2つのハードリンクを持つファイルがあります。

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

そもそもそのハードリンク/home/you/myfileがどのようにそこに到達したか気にしないでください。たぶんrootそこに置いてください。

この例の考え方は、ハードリンクを削除できるようにすることです/home/you/myfile。結局のところ、それはあなたのディレクトリを混乱させています。あなたはありませんし、内部に存在しないものを制御することができるはずです/home/you。また、removeを実行すると/home/you/myfile、実際にファイルを削除していないことに注意してください。リンクを1つだけ削除しました。

スティッキービットは、ファイルを含むディレクトリに設定されている場合ことに注意してください（などのショーアップtでls）、あなたがやる（あなたがディレクトリを所有していない限り）それを削除することが許可されるために、ファイルの所有者である必要性を。通常、スティッキービットはオンに設定されてい/tmpます。

ファイルを削除するには、ファイルが存在するディレクトリに書き込むことができる必要があります。

あなたは、このようにしないと経由して、あなたは「スティッキー」ビットを設定することができchmod +t dirますが、途中、最近のOS上にある場合（この機能は、SunOSの1986年を中心に導入されました）。

よりきめ細かくしたい場合は、ZFSのような最新のACL実装を備えたファイルシステムが必要です。NTFSに基づく標準のNFSv4 ACLには、ユーザーごとのファイル固有の削除アクセス許可とディレクトリの「delete_child」アクセス許可のサポートが含まれています。

ロジックは家のロジックと似ています。所有者またはテナントは、ゲストの所有者に関係なく、どのゲストを捨てるかを決定します。また、別の家で歓迎されている（他の誰かのディレクトリに別のハードリンクがある）追い出されたゲストは、外で凍結することはありません。