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

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

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