Доступ для записи без доступа для чтения
Традиционно, это было сделано этот путь из-за особенностей аппаратных средств DEC, на которых это было разработано. Было более выгодно купить маленький, быстрый диск для корня и подкачки и больший, более медленный диск для пользовательских данных (/usr). До некоторой степени конвенция, просто застрявшая.
Однако существуют все еще некоторые причины того, чтобы сделать это. Несколько общих:
Помещение / загружается на отдельный, небольшой раздел близко к началу диска. Более старый ПК встроенное микропрограммное обеспечение BIOS только загрузился бы от первых 1 024 дорожек диска. Это, менее вероятно, будет проблемой с современными аппаратными средствами.
Помещение занятых разделов такой как
/varили/tmpна отдельные диски для удаления узких мест на доступе к пользовательским данным.Различные файловые системы на различных разделах. Например, можно хотеть использовать файловую систему журналирования для
/usrно не для разделов, которые размещают файлы для DBMS, такие как Oracle - DBMS делает свое собственное журналирование, и файловая система журналирования может наложить значительные издержки.Наличие пользовательских данных по отдельному диску или разделу помогает переместить его на больший диск без обширного оперативного вмешательства на машине.
Можно хотеть смонтировать совместно используемые данные, такие как корневые каталоги или двоичные файлы приложения по NFS.
fsckзанимает много времени на больших объемах для определенных типов файловой системы. Можно хотеть иметь различные графики обслуживания файловой системы для системных (частых) областей и пользовательских (менее частых) областей.
Это не ошибка, это - featureTM (Кроме того, просто последствие универсального подхода Unix к полномочиям).
Кроме подобного Dropbox поведения в случае каталогов (как описано BillThor), доступ только для записи необходим для некоторого специального предложения (псевдо-) файлы под /proc и /sys. Такие файлы используются, чтобы установить некоторый драйвер или свойства ядра или инициировать системное действие. Вы не можете считать их, потому что они используются только для односторонней передачи сигналов - можно только повторить некоторый текст/данные им. Для нахождения таких файлов можно использовать
find /proc/[^0-9]* /sys -perm /222 ! -perm /444
Заметьте, что, так как эти файлы используются для усовершенствованной (потенциально опасной) конфигурации системы, только root имеет доступ для записи к ним (в большинстве случаев).
Главная причина позволить доступ для записи без доступа для чтения состоит в том, что он упрощает управление полномочиями, и в ядре и в пользовательских программах. Существует два полномочий, один для чтения и один для записи, и ими управляют независимо. Это не ошибка, так как зарегистрированное поведение совпадает с фактическим поведением и нет никакого серьезного основания потребовать другого поведения.
Наличие полномочий записи без полномочий чтения не имеет большого смысла для регулярных файлов. Это действительно имеет смысл для различных специальных файлов.
- Некоторые системы позволяют файлы только добавления. Это полезно для файлов журнала, например. Может иметь смысл позволять многим пользователям создавать записи в журнале, но не позволять им стирать или перезаписывать существующие записи (следовательно: запишите разрешение, но атрибут только добавления), ни позволить им читать записи других (следовательно: никакое разрешение чтения).
- Программе можно позволить записать в именованный канал, не будучи позволенным читать из него.
- Некоторые устройства только для записи. Например, устройство звукового вывода, подключенное к громкоговорителю, но никакому микрофону, должно иметь разрешение записи, но никакое разрешение чтения.
- Существуют различные специальные файловые системы, где чтение или запись в файл имеют непосредственный эффект вместо того, чтобы получить или добавить данные к устройству хранения данных. Например, в соответствии с Linux, существуют различные файлы под
/procи/sysэто позволяет программам пространства пользователя отправлять команды в ядро путем записи в конкретный файл. Если та команда не обеспечивает обратной связи, специальный файл сделан только для записи.
Нет это не ошибка. Однако я не вижу, что это обычно относилось к файлам.
Я чаще всего видел доступ только для записи на каталогах Dropbox. Пользователи могут добавить файлы к каталогу, но не видеть, который файлы, существуют.
Для файла обычного текста доступ только для записи подходил бы для доступа типа Dropbox.
Установка доступа только для записи для себя не была бы ужасно полезна, но не разрешение его усложнит код полномочий.
Править: Файлы Dropbox вряд ли будут полезны. Однако это могло бы быть полезно для некорневых журналов, поскольку это сделает более трудным перезаписать записи в журнале. Если можно считать файл, намного легче определить, где записать заменяющую запись в журнале. Однако я не знаю никого, кто настраивает их журналы как это. Распространено использовать удаленный вход для предотвращения локальной модификации записей в журнале.
Устанавливание правил, на которых комбинации разрешения допустимы, могло привести к предотвращению непредвиденных полезных полномочий. Много комбинаций имеют больше смысла на группе или мировом уровне, чем уровень владельца. Любые попытки предотвратить доступ владельцем могут быть легко переопределены. Однако они могут быть полезными для принуждения трезвой секунды все же.
-
1"файл Dropbox" на самом деле имел бы мало смысла. Это могло только использоваться для записи некоторых данных и даже если бы это было сделано читаемым в какой-то момент, то его содержание не показало бы реальной трассировки того, что происходило с ним, потому что это, возможно, было ранее стерто или удалено. – rozcietrzewiacz 14.10.2011, 13:22