Почему исполняемые файлы в / usr / sbin доступны для записи root?

Не могли бы вы объяснить, почему двоичный скомпилированный файл (например, в /usr/sbin) имеет разрешение на запись для rootпользователя?

Для меня это составлено. Это означает, что прямая запись не имеет смысла и может как-то подвергнуть файл какой-либо проблеме безопасности.

Сценарий (например, bashфайл) может быть доступен для записи, потому что это в основном текстовый файл, но почему он одинаков для скомпилированного файла, где, насколько я знаю, запись не нужна?

Заранее благодарю за отзыв.

— t1m0th33
источник

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

— Эрик Ренуф

Обратите внимание, что по иронии судьбы двоичные файлы - это единственные файлы, которые мы обычно пишем / редактируем непосредственно на диске. Мы не можем сделать это с текстовыми файлами, такими как скрипты, потому что текстовые модификации включают в себя не запись в файл, а добавление дополнительных байтов в середине файла или удаление байтов в середине файла. Это невозможно сделать с помощью fseek fwrite. Поэтому для текстовых файлов мы обычно читаем в ОЗУ, затем удаляем старый файл и записываем содержимое ОЗУ на диск (т.е. перезаписываем). Кроме того, когда вы устанавливаете, перемещаете или заменяете исполняемые файлы, вы записываете на диск, поэтому вам нужны разрешения на запись.

— slebetman

@ Slebetman: Вы можете напрямую редактировать текстовые файлы. Например, откройте файл, расширьте его, отобразите в памяти, используйте, memmove()чтобы переместить последнюю часть в конец и открыть отверстие, а затем вставьте новый текст в отверстие. Или вы можете использовать серию pread()/, pwrite()чтобы сделать то же самое.

— Zan Lynx

@EricRenouf На самом деле, разрешения на запись в двоичный файл не требуются для обновления пакета, который его содержит. При обновлении пакета старый двоичный файл не записывается в; на самом деле это невозможно, если бинарный файл в данный момент запущен (поиск ETXTBSY). Вместо этого старый двоичный файл удаляется , а новый двоичный файл записывается в новый файл с тем же именем. Удаление файлов не требует разрешения на запись в них, просто в каталог, в котором они находятся (т. Е. /usr/sbin/).

— Марсель

@marcelm: Строго говоря, вы не просто используете fseek и write, вы буферизируете остаток в RAM. Вы также можете буферизовать остаток в другой файл. Или вы можете написать новый контент в новый файл. Ничто из этого не позволяет расширять текстовые файлы без какого-либо большого буфера.

— Slebetman

На самом деле не имеет значения, являются ли файлы в /bin(или любом другом стандартном каталоге, где хранятся исполняемые файлы) доступными для записи пользователем root или нет. На сервере Linux, который я использую, они доступны для записи root, но на моей машине с OpenBSD это не так.

Пока они не доступны для записи ни группой, ни «другим»!

Нет проблем с безопасностью, например,

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

Если кто-то хочет перезаписать его, он должен быть пользователем root, а если он rootи перезаписать его, то он либо

установка новой версии или
неуклюжий или
злоумышленник с правами root уже .

Еще одна вещь, которую следует учитывать, - это то, что root может записывать в файл независимо от того, защищен он от записи или нет, потому что ... root.

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

Не изменяйте права доступа ко всему сейчас! Это может привести к разного рода хаосам и может привести к путанице в работе менеджеров пакетов, которые могут проверить правильность установки разрешений. Это также может сделать систему уязвимой, если вы случайно неверно измените разрешения для критически важного приложения.

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

Из комментариев и в чате , был звонок для некоторой истории.

История разрешений для двоичных файлов в Linux - это не то, о чем я ничего не знаю. Можно предположить, что они просто унаследовали разрешения от каталога или просто от umaskLinux по умолчанию , но я действительно не знаю.

Что я знаю, так это то, что OpenBSD устанавливает двоичные файлы в базовой системе ¹ с режимом разрешений 555 по умолчанию ( -r-xr-xr-x). Это указывается во фрагменте Makefile, в /usr/share/mk/bsd.own.mkкотором установлено BINMODEзначение 555 (если оно уже не установлено). Это позже используется при установке исполняемых файлов во время make buildв /usr/src.

Я просмотрел аннотированный журнал CVS для этого файла и обнаружил, что эта строка в файле не изменилась, поскольку она была импортирована из NetBSD в 1995 году.

В NetBSD файл был впервые помещен в CVS в 1993 году с BINMODEзначением 555.

Похоже, что в проекте FreeBSD использовался тот же файл, что и в NetBSD, по крайней мере с 1994 года , и при последующей фиксации в сообщении о фиксации добавляется подсказка о том, что старые файлы были из версии 4.4BSD дистрибутива программного обеспечения Berkeley.

Кроме того, CSRG в Беркли хранил источники в SCCS, но их хранилище доступно в форме Git на GitHub ² . Файл , который мы даем на forencic здесь для пропитки , кажется, было совершено по Keith Бостик (или кто - то в непосредственной близости от него) в 1990 году.

Вот такая история. Если вы хотите почему , тогда, я полагаю, нам придется спросить Кейта. Я как бы надеялся увидеть сообщение о фиксации изменений, говорящее « это должно быть 555, потому что ... », но нет.

¹ _{Системы BSD более строго разделены на «базовую систему» и «сторонние пакеты» (порты / пакеты), чем Linux. Базовая система представляет собой единое целое, которое предоставляет полный набор средств для запуска операционной системы, в то время как порты или пакеты рассматриваются как «локальное программное обеспечение» и устанавливаются под ним /usr/local.}

² _{Также доступно более полное GitHub-хранилище версий Unix, начиная с 70-х годов .}

— Кусалананда
источник

Спасибо за ответ. Разрешение на запись является нормальным, поскольку это не имеет значения, будучи пользователем root (он может делать все что угодно). Но, поскольку это не имеет большого значения, почему бы нам не поставить разрешение на запись, если оно одинаковое с самого начала? Это произвольное решение?

— t1m0th33

@ t1m0th33 Я верю, что это может быть произвольное решение, которое кто-то принял, да. Как я уже говорил, в моей системе OpenBSD файлы в этих местах недоступны для записи root.

— Кусалананда

Я не думаю, что это осознанное решение кого-либо. Менеджер пакетов по умолчанию устанавливает файл с битами разрешений, с которыми они работали в процессе сборки; при компоновке компоновщик создал файлы с разрешениями 755, потому что это то, что вы получаете, когда вычитаете umask из 777, а корень umask (на машинах сборки поставщика ОС) имел при сборке 022, потому что 022 - это umask по умолчанию для всех и это будет 222 для root было бы бессмысленной дополнительной работой.

— Хеннинг

+1 за "Не меняй разрешения на все сейчас!" Я вижу так много вопросов , как , что на ASK Ubuntu , где пользователь сделал chmod -R на /usrили /var, и удивление - их sudoне работает , или еще что - то не работает.

— Сергей Колодяжный

Исторически отсутствие разрешения на запись для root не оказывало никакого влияния (root может chmod что угодно и даже не нужно, потому что root никогда не получает EPERM при открытии или записи в любом случае). Интересно, началось ли это 555, потому что стало возможным ограничить права root (когда впервые появились уровни безопасности - примерно в то же время, что и 4.4BSD или ранняя