9

Я не мог найти ответы на эти три вопроса:

  • Кто такие "другие", если мы предоставляем все сервисы на нашем сервере пользователю, "другие" не существуют, верно? Например, если мы ставим Apache для пользователя, и мы устанавливаем /var/www chowned для apache , и мы вводим chmod 700 это должно работать, верно?

  • В чем разница между "выполнить" и "прочитать"?

  • Каковы права доступа к файлам по умолчанию для всей системы после чистой установки (например, в Ubuntu)?

5 ответов5

14

Кто такие "другие", если мы предоставляем все сервисы на нашем сервере пользователю, "другие" не существуют, верно? Например, если мы ставим Apache для пользователя, и мы устанавливаем /var/www chowned для apache , и мы вводим chmod 700 это должно работать, верно?

Вот как работают разрешения, объясненные очень кратко:

  • Первая цифра предназначена для фактического владельца файла (проверьте, кто владеет файлом с помощью ls -l и измените его с помощью chown)

  • Вторая цифра относится к группе файла (хотя владелец файла не обязательно должен быть в той же группе, которая владеет файлом)

  • Третья цифра - это кто-то еще, то есть не владелец файла, а все, кто не входит в группу.

Поэтому, если вы chmod файл на 700 и он принадлежит apache , даже ваш "обычный" пользователь не сможет прочитать, записать или выполнить его. Это очень ограничительно и необходимо только в редких случаях - например, когда вы хотите защитить свой закрытый ключ SSH, он получает 600 разрешений. Для Apache это может даже привести к другим проблемам, кроме того факта, что с вашей обычной учетной записью пользователя вы не сможете больше редактировать файлы в /var/www .

Поэтому, вообще говоря, вам не нужно удалять разрешения на чтение (x00) для других.

Вы можете позволить apache владеть каталогом /var/www , но с 644 (только для чтения для других), может быть. Другой подход, который я часто использую, - это добавление вашего собственного пользователя и пользователя Apache в новую группу www-users , а затем chmodding файлы в /var/www в 775 . Таким образом, вы и Apache можете писать в файлы. Смотрите здесь для получения дополнительной информации: Групповые разрешения для Apache


В чем разница между "выполнить" и "прочитать"?

Исполняемые файлы могут запускаться непосредственно пользователем - прямо из оболочки. Чтобы продемонстрировать это, давайте напишем короткий файл и назовем его "тест". Добавьте следующий контент:

echo "I am executable"

Сохраните файл. Теперь в вашей оболочке попробуйте войти ./test . Вы получите ошибку « -bash: ./test: В доступе отказано ». Это связано с тем, что по умолчанию вновь созданные файлы не имеют разрешений на выполнение. Если вы добавите разрешение на выполнение, оно будет работать.

$ chmod +x test
$ ./test
I am executable

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

Это, например, системные программы, которые в основном находятся в /bin . Запустите ls -l /bin чтобы проверить их разрешения. Как видите, они принадлежат пользователю root , и вы не можете их изменить, но вы всегда можете выполнить их.

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

Чтобы узнать больше о разрешениях Unix, прочитайте статью в Википедии. Основные разрешения, которые вы знаете как «чтение-запись-выполнение», существуют уже давно, но являются лишь частью того, что вы называете списками контроля доступа - которые предлагают гораздо больше функциональности, чем эта.


Каковы права доступа к файлам по умолчанию для всей системы после чистой установки (например, в Ubuntu)?

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

Другие каталоги, такие как ваша домашняя папка, очевидно, принадлежат вашему пользователю. Возможно, имеет смысл отказать в разрешении на чтение другим пользователям на машине, если они разделены между несколькими людьми - в конце концов, вы не хотите, чтобы ваши личные материалы были раскрыты.

Наконец, некоторые файлы исполняются по умолчанию (например, в /bin), а другие - нет (например, файлы конфигурации в /etc).

Стандарт Иерархии Файловой системы определяет предполагаемое использование для каталогов, найденных в системах Linux. Вы можете почти "угадать", какие разрешения должны быть основаны на том, что вы хотите сделать с каталогом.

5

Просто хочу добавить, что разрешение на выполнение имеет разные эффективные значения для каталогов:

Для файлов:

  • Читать: если содержимое файла можно прочитать
  • Запись: если пользователь или процесс может записать в файл (изменить его содержимое)
  • Выполнить: если файл может быть выполнен

Для папок:

  • Читайте: если список каталогов может быть получен
  • Запись: Если пользователь или процесс может каким-либо образом изменить содержимое каталога: создайте новые или удалите существующие файлы в каталоге или переименуйте файлы.
  • Выполнить: если пользователь или процесс могут получить доступ к каталогу, то есть перейти к нему (сделать его текущим рабочим каталогом)

Нет, отдельного разрешения на удаление для каталогов нет.

(Получил эту информацию здесь.)

0

Я не эксперт по Linux, но я все же пытаюсь ответить.

Каждая запись файловой системы имеет ассоциированного пользователя и группу. Полномочия пользователя обрабатываются флагами пользователя. Полномочия пользователей, которые входят в одну группу, обрабатываются флагами "группа". Все остальные пользователи обрабатываются флагами "другие".

"читать" означает, что он говорит. "выполнить" означает, что вы можете запустить файл (например, команду) или вы можете перечислить каталог.

Что касается разрешения по умолчанию, я не уверен. Я думаю, это может быть настроено как-то и, следовательно, может быть различным для каждого пользователя.

0

Чтобы дать вам достойный ответ на вопрос 2, по крайней мере, вот сводная таблица, показывающая, что вы можете / не можете делать:

+--------------------------------------------------+
| Execute Yes (./file.sh) | Read Yes (vim file.sh) |
|--------------------------------------------------|
| Execute Yes (./file.sh) | Read No (ERROR)        |
|--------------------------------------------------|
| Execute No (ERROR)      | Read Yes (vim file.sh) |
|--------------------------------------------------|
| Execute No (ERROR)      | Read No (ERROR)        |
+--------------------------------------------------+

Важно помнить, что это не ПОЛЬЗОВАТЕЛЬ, считывающий файл файла в память для его выполнения, это КЕРНЕЛ, который делает это от имени ПОЛЬЗОВАТЕЛЯ.

0

Это может быть сложно, если вы хотите исключить все остальные. Посмотрите на этот список из моего файла /etc /passwd (права доступа и тому подобное удалены для ясности):

root демон демон sys sync игры man lp mail новости прокси uucp www-список резервных копий irc gnats libuuid syslog messagebus usbmux haldaemon nobody

a {это я, и ниже вот вещи, которые я установил, прежде всего, поставленные с системой}

avahi mysql пульс rtkit saned робость дидивики

Например, удалите разрешения из lp или uucp, и вы прервете печать. удалите разрешение из bin, sys или daemon, и, вероятно, многое сломается. irc, игры, почта, новости и резервные копии могут быть безопасно удалены (если вы не используете их через систему, а не через браузер). остальное я оставляю на ваши навыки поисковой системы.

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

Выполнить - это разрешение на запуск кода. Чтение - это разрешение на просмотр (и копирование?) только.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .