Как я смог удалить файл, принадлежащий корню без sudo

3340
hjpotter92

У меня был следующий вывод для ls -lFh:

-rw-r--r-- 1 hjpotter92 hjpotter92 926 Aug 2 18:40 static.yaml drwxr-xr-x 5 hjpotter92 hjpotter92 4.0K Sep 12 19:40 templates/ -rw-r--r-- 1 root root 1.5K Sep 12 20:09 xyz

Я вошел как hjpotter92. У моего пользователя нет NOPASSWDзаписи в sudoersсписке. Может кто-нибудь объяснить поведение, когда я попробовал следующее:

$ which rm rm: aliased to rm -i $ rm xyz rm: remove write-protected regular file 'xyz'? y $ sudo rm xyz rm: cannot remove 'xyz': No such file or directory $ ls -lFh total 176K <a lot of other files> -rw-r--r-- 1 hjpotter92 hjpotter92 926 Aug 2 18:40 static.yaml drwxr-xr-x 5 hjpotter92 hjpotter92 4.0K Sep 12 19:40 templates/
7
Не могли бы вы включить вывод `ls -lFh` для родительского каталога? jrtapsell 6 лет назад 1

1 ответ на вопрос

15
Jaroslav Kucera

В этом случае существуют важные разрешения на запись в каталог, где находится файл. Так что если вы можете написать каталог, вы также можете удалить файлы там.

Документировано ли поведение где-нибудь? Не приведет ли это к возможным проблемам безопасности? hjpotter92 6 лет назад 0
С точки зрения безопасности это нормально. Если у вас нет прав на запись в файл, вы не можете изменить его. Однако, если файл находится в каталоге, куда вы можете записать, вы можете изменить содержимое каталога. А содержимое каталога состоит из файлов или подкаталогов. Jaroslav Kucera 6 лет назад 2
В более общем смысле, один файл может существовать в нескольких каталогах (через жесткие ссылки). Удаление файла из каталога не обязательно удаляет его содержимое с диска. Max 6 лет назад 6
@ hjpotter92: Это хорошо написано во многих документах. Есть один важный момент, запрещающий удаление файла, который не принадлежит вам. В общем, процессы с привилегиями должны иметь контроль над каталогами (весь путь), в которые они пишут. Giacomo Catenazzi 6 лет назад 2
Конечно это задокументировано. Упомянутый в этом FAQ из девяностых http://www.ibiblio.org/pub/historic-linux/distributions/redhat-5.1/i386/doc/FAQ/html/Linux-FAQ-6.html#ss6.12. https://en.wikipedia.org/wiki/File_system_permissions#Permissions говорит: «Разрешение на запись дает возможность изменять файл. Когда установлено для каталога, это разрешение дает возможность изменять записи в каталоге. Это включает в себя создание файлы, удаление файлов и переименование файлов. " Владелец файла не имеет значения. Stéphane Gourichon 6 лет назад 5
Это своего рода недостаток в модели Unix. Удаление файла фактически является модификацией файла, а не только каталога. Счетчик ссылок inode уменьшается на единицу. Более того, если этот refcount достигнет нуля, файл станет мусором и его хранилище будет переработано. Обе они являются разрушительными манипуляциями с объектом, который вам не принадлежит и на который у вас нет разрешения на запись. Kaz 6 лет назад 1
@ Kaz, если вы не сможете создать жесткую ссылку на файл без разрешения на запись в файл, учитывая, что это увеличивает количество ссылок в inode? Sneftel 6 лет назад 0
@Sneftel Это также проблематично и может быть использовано для совершения следующего взлома. Пользователь A и B находятся в системе с квотами. A имеет несколько хороших (и больших) файлов, принадлежащих A. B нравятся эти файлы. B делает жесткую ссылку на эти файлы в каталоге, недоступном для A. B наслаждается файлами, не считая их до своей квоты. A удаляет файлы, чтобы освободить место, тем самым теряя свою последнюю доступную ссылку (забыл принять меры по обрезанию объектов до нулевой длины в первую очередь!). Они продолжают рассчитывать на квоту А. Kaz 6 лет назад 0
@Kaz, для которого требуется файловая система с сомнительной реализацией квоты. Это не присущий недостаток в системе разрешений. Mark 6 лет назад 0
@ Отметить любую реализацию квот под вопросом. Хотя файлы связаны между собой как в каталогах A, так и в каталогах B, на чью квоту они должны рассчитывать? Предположим, что они считаются против B, когда они находятся только в каталоге B. A может использовать открытый каталог, принадлежащий B, чтобы хранить там файлы и обходить квоты. Kaz 6 лет назад 0
@ Марк Я думаю, что реализация Linux-квоты просто так: она ограничивает количество inode и сколько блоков может выделить пользователь. Я думаю, что это просто считается собственностью объекта. Если инод принадлежит вам, то он считается как инод по отношению к количеству ваших инодов, а все его блоки соответствуют количеству ваших блоков, независимо от того, где он находится в дереве. Kaz 6 лет назад 0

Похожие вопросы