web-dev-qa-db-ja.com

なぜ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>

これは許されるべきではないと思っていました。ユーザーは自分の所有権の下にあるファイルのみを削除できるはずですか？なぜこれが許可されるのかを誰かが明らかにすることはできますか？これを回避する方法は何ですか？親ディレクトリの書き込み権限を制限して、予期しないファイルの削除を許可しないようにすることができます。

filespermissionsrmhistoryarchitecture
53
mtk

これが許可される理由は、ファイルの削除が実際に行うことと関連しています。概念的には、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の削除を許可する必要があるということです。結局のところ、それは雑然としていますyourディレクトリ。 あなたは、/home/you内に存在するものと存在しないものを制御できる必要があります。また、/home/you/myfileを削除する場合は、実際にファイルを削除していないことに注意してください。削除したリンクは1つだけです。

ファイルを含むディレクトリにスティッキービットが設定されている場合（tにlsとして表示される）、doがファイルの削除を許可するため（ファイルを所有していない場合）。通常、スティッキビットは/tmpに設定されます。

101
Celada

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

これが気に入らない場合は、最近のOSの半分を使用している場合、chmod +t dirを介して「スティッキー」ビットを設定できます（この機能は1986年頃にSunOSで導入されました）。

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

9
schily

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

0
rackandboneman