Доступ к записи без доступа для чтения

Возможно ли, чтобы пользователь имел доступ на запись к файлу и не мог его прочитать? Как это возможно?

Я пробовал следующие команды:

[email protected]:~/posix/io$ touch filetest
[email protected]:~/posix/io$ ls -l filetest
-rw-r--r-- 1 debianbox debianbox 0 14 oct.  03:10 filetest

[email protected]:~/posix/io$ echo "Hello World" > filetest
[email protected]:~/posix/io$ cat filetest
Hello World

[email protected]:~/posix/io$ chmod u-r filetest
[email protected]:~/posix/io$ cat filetest
cat: filetest: Permission forbidden

[email protected]:~/posix/io$

Как вы можете видеть здесь, я пишу, но не читаю доступ к этому файлу. Как это может быть возможным? Это считается ошибкой? Если нет, в какой ситуации это будет полезно?

11 голосов | спросил Dimitri 14 +04002011-10-14T05:26:38+04:00312011bEurope/MoscowFri, 14 Oct 2011 05:26:38 +0400 2011, 05:26:38

3 ответа


16

Это не ошибка, это функция TM (также как следствие универсального подхода UNIX к разрешениям).

Помимо поведения, подобного Dropbox, в случае каталогов (как описано в BillThor), доступ к записи необходим для некоторых специальных (псевдо) файлов в /proc и /sys. Такие файлы используются, чтобы установить некоторые свойства драйвера или ядра или вызвать действие системы. Вы не можете их прочитать, потому что они используются только для однонаправленной сигнализации - вы можете только откликнуться на некоторые тексты /данные. Чтобы найти такие файлы, вы можете использовать

find /proc/[^0-9]* /sys -perm /222 ! -perm /444

Обратите внимание: поскольку эти файлы используются для расширенной конфигурации системы (потенциально опасно), только root имеет доступ на запись к ним (в в большинстве случаев).

ответил rozcietrzewiacz 14 +04002011-10-14T11:29:45+04:00312011bEurope/MoscowFri, 14 Oct 2011 11:29:45 +0400 2011, 11:29:45
15

Основная причина разрешить доступ на запись без доступа к чтению заключается в том, что он упрощает управление разрешениями как внутри ядра, так и в пользовательских программах. Существует два разрешения: одно для чтения и одно для записи, и они управляются независимо. Это не ошибка, так как документированное поведение совпадает с фактическим поведением, и нет никаких оснований требовать другого поведения.

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

  • Некоторые системы разрешают файлы только для добавления. Это полезно, например, для файлов журналов. Имеет смысл разрешить многим пользователям создавать записи журнала, но не разрешать им удалять или перезаписывать существующие записи (отсюда: разрешение на запись, а только атрибут append), а также не позволять им читать записи других (следовательно: нет разрешение на чтение).
  • Программе может быть разрешено писать в именованный канал, не будучи допущенным к чтению.
  • Некоторые устройства предназначены только для записи. Например, устройство вывода звука, подключенное к громкоговорителю, но не имеющее микрофона, должно иметь разрешение на запись, но не имеет разрешения на чтение.
  • Существуют различные специальные файловые системы, в которых чтение или запись в файл имеет непосредственный эффект, вместо того, чтобы извлекать или добавлять данные в хранилище. Например, под Linux существуют различные файлы в /proc и /sys, которые позволяют программам пользовательского пространства отправлять команды ядру, записывая их в конкретный файл. Если эта команда не дает обратной связи, специальный файл создается только для записи.
ответил Gilles 16 +04002011-10-16T03:29:16+04:00312011bEurope/MoscowSun, 16 Oct 2011 03:29:16 +0400 2011, 03:29:16
2

Нет, это не ошибка. Однако я не вижу, чтобы это обычно применялось к файлам.

Я чаще всего видел доступ только для записи в каталогах Dropbox. Пользователи могут добавлять файлы в каталог, но не могут видеть, какие файлы существуют.

Для обычного текстового файла для доступа к типу Dropbox подходит только доступ.

Настройка записи только для доступа не будет ужасно полезной, но не позволит ей усложнить код разрешений.

EDIT: файлы Dropbox вряд ли будут полезны. Однако это может быть полезно для журналов без полномочий root, так как это затрудняет перезапись записей журнала. Если вы можете прочитать файл, гораздо легче определить, где записать запись замещающего журнала. Однако я не знаю никого, кто устанавливает свои журналы таким образом. Обычно для удаленного локального изменения записей журнала используется дистанционное ведение журнала.

Установление правил, по которым допустимы комбинации разрешений, может привести к предотвращению непредвиденных полезных разрешений. Многие комбинации имеют больше смысла на уровне группы или мира, чем уровень владельца. Любые попытки предотвратить доступ владельца могут быть легко переопределены. Тем не менее, они могут быть полезны, чтобы заставить трезвую секунду, хотя.

ответил BillThor 14 +04002011-10-14T06:51:54+04:00312011bEurope/MoscowFri, 14 Oct 2011 06:51:54 +0400 2011, 06:51:54

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132