Чому rm дозволено видаляти файл у власності іншого користувача?


52

З публікації Чому можна видалити файли, доступні лише для читання? Я розумію, що 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.


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. Чи слід перешкоджати Бобі видаляти посилання, яке він створив?   І чи слід дозволити Ал видалити (від’єднати), /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біт чи ні. Якщо ви пов'язуєте файл з чужим каталогом, ви повинні бути готові до того, щоб хтось інший міг його видалити. Альтернативою було б спершу створити власний субдиректор і додати його замість нього, оскільки власник не зможе видалити цей підкаталог, якщо він не порожній.
Stéphane Chazelas

6
Ви описуєте ситуацію в омані. Технічно файл не знаходиться в каталозі; швидше, ім'я для файлу знаходиться в каталозі, і rmце операція над каталогом, а не над файлом. Файл видаляється, коли остання посилання на нього видаляється, але технічно це є побічним ефектом.
reinierpost

0

Логіка подібна до дому будинку: власник або орендар вирішує, яких гостей викинути, незалежно від того, хто є гостями. Також виселений гість, який вітається в іншому будинку (має ще одне тверде посилання в чужому довіднику), не замерзне на вулиці.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.