Почему rm разрешено удалять файл, принадлежащий другому пользователю?

52

Из поста Почему 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>

Я думал, что это не должно было быть позволено. Пользователь должен иметь возможность удалять только файлы, находящиеся в его собственности? Может кто-то пролить свет на то, почему это разрешено? и как этого избежать? Я могу думать только об ограничении разрешения записи родительского каталога, чтобы запретить неожиданное удаление файла.

холодный морской тропический воздух
источник

Ответы:

100

Причина, по которой это разрешено, связана с тем, что фактически делает удаление файла. Концептуально, rmзадача состоит в том, чтобы удалить запись имени из каталога. Тот факт, что файл может стать недоступным, если это было единственное имя файла, и что индекс и пространство, занимаемое файлом, могут быть восстановлены в этот момент, почти случайно. Имя системного вызова, который 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.

Celada
источник
6
С помощью залипшего бита в каталоге вы должны иметь возможность изменить файл, чтобы разрешить его удаление. То есть, если файл принадлежит кому-то еще в той же группе, что и вы, и группа может записать в файл, вы можете удалить файл. Следствие: любой может удалить файл с открытым разрешением на запись. (Конечно, все зависит от возможности изменить каталог.)
Джонатан Леффлер
1
Возможно, я вас неверно истолковываю, но разве вы не говорите, что я могу удалить -rw-rw-rw- 1 root root 0 Sep 1 11:11 /tmp/fooкак своего обычного пользователя (« /tmpлипкий»), потому что мне разрешено это писать? Все же я не могу.
Селада
4
Я полагаю, что сценарий me/ youстановится более ясным, если вы предположите, что пользователь (тот, кто не владеет файлом) создал ссылку. Местоимения трудно использовать; допустим, Ал создает /home/al/file1, а Боб, у которого есть доступ для выполнения (и, возможно, чтения) /home/al, жестко связывает файл /home/bob/als_file. Если Боб не допускать удаления ссылки , что он создал?   И следует ли разрешить Al удалять (отменять связь), /home/bob/als_fileкогда у него нет прав на запись /home/bob? Эта дорога ведет к хаосу.
Скотт
2
@JonathanLeffler: Как показывает пример Скотта, нет, отсутствие связей и усечение не дают одинакового чистого результата, когда в игре присутствуют жесткие ссылки.
Кевин
6
@Kevin Я думаю, дело в том, что если у кого-то есть разрешение на запись в файл, и он может уничтожить его содержимое, ему также может быть разрешено удалить его (если он также имеет разрешение на запись в каталог). Обратное не применимо - возможность удалить файл из одного каталога не означает, что он должен быть в состоянии уничтожить содержимое, поскольку они могут быть доступны из другого каталога. Это логика, лежащая в основе работы залипшего бита.
Бармар
9

Чтобы удалить файл, вам просто нужно иметь возможность записать в каталог, в котором находится файл.

Если вам это не нравится, вы можете установить «липкий» бит, chmod +t dirесли вы используете половинную ОС (эта функция была введена в 1986 году в SunOS).

Если вы хотите быть более детализированными, вам нужна файловая система с современной реализацией ACL, такой как ZFS. Стандартные списки ACL для NFSv4, основанные на NTFS, включают в себя поддержку разрешений на удаление файлов для каждого пользователя и разрешение «delete_child» для каталогов.

Шили
источник
9
Обратите внимание, что для добавления tбита вам необходимо иметь каталог. И если у вас есть каталог, вы всегда можете удалить файлы независимо от того, установлен tбит или нет. Если вы свяжете файл с чьим-либо другим каталогом, вы должны быть готовы к тому, что кто-то другой сможет его удалить. В качестве альтернативы можно было бы сначала создать свой подкаталог и вместо этого добавить туда свой файл, поскольку владелец не сможет удалить этот подкаталог, если он не пустой.
Стефан Шазелас
6
Вы описываете ситуацию обманчиво. Технически, файл не находится в каталоге; скорее, имя файла находится в каталоге и rmявляется операцией над каталогом, а не над файлом. Файл удаляется при удалении последней ссылки на него, но технически это побочный эффект.
фоторепортаж
0

Логика аналогична логике дома: владелец или арендатор решает, кого из гостей выбрасывать, независимо от того, кому принадлежат гости. Кроме того, выселенный гость, которого можно встретить в другом доме (имеет другую жесткую ссылку в чужом каталоге), не замерзнет на улице.

rackandboneman
источник