Как работают права доступа к файлам для пользователя «root»?

У меня есть следующий файл:

---------- 1 Steve Steve 341 2017-12-21 01:51 myFile.txt

Я переключил пользователя на rootв терминале, и я заметил следующее поведение:

• Я могу прочитать этот файл и написать в него.

• Я не могу выполнить этот файл.

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

Может кто-нибудь объяснить мне или указать мне учебник, который объясняет все правила, которые применяются, когда rootпользователь имеет дело с файлами и каталогами?

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

Вкратце, вы уже описали, как проверки контроля доступа работают для привилегированного процесса. Вот как на это влияют различные возможности:

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

На самом деле это не относится к исполняемым файлам, которые не помечены как исполняемые. Комментарий вgeneric_permission ( fs/namei.c), до проверки прав доступа к файлам, говорит , что

ЦАПы чтения / записи всегда могут быть переопределены. Исполняемые ЦАПы могут быть переопределены, когда установлен хотя бы один бит exec.

И код проверяет, что установлен хотя бы один xбит, если вы пытаетесь выполнить файл. Я подозреваю, что это только удобная функция, предотвращающая случайный запуск случайных файлов данных и получение ошибок или странных результатов.

В любом случае, если вы можете переопределить разрешения, вы можете просто сделать исполняемую копию и запустить ее. _{(Хотя в теории это может иметь значение для файлов setuid процесса, он мог переопределять права доступа к файлам ( CAP_DAC_OVERRIDE), но не имел других связанных возможностей ( CAP_FSETID/ CAP_FOWNER/ CAP_SETUID). Но с CAP_DAC_OVERRIDEвозможностью редактирования /etc/shadowи тому подобного, поэтому он примерно равен в любом случае просто иметь полный root-доступ.)}

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

Переопределение залипания в каталогах упоминается только в разделе CAP_FOWNER, так что, кажется, этого CAP_DAC_OVERRIDEбудет недостаточно, чтобы игнорировать это. (Это даст вам разрешение на запись, но, как правило, в липких каталогах оно у вас есть и +tограничивает его.)

_{(Я думаю, что специальные устройства здесь считаются «файлами». По крайней мере, generic_permission()есть только проверка типа для каталогов, но я не проверял за этим.)}

Конечно, все еще существуют ситуации, когда даже возможности не помогут вам изменить файлы:

• некоторые файлы в /procи /sys, так как они не являются настоящими файлами
• SELinux и другие модули безопасности, которые могут ограничивать root
• chattrнеизменяемые +iи добавляются только +aфлаги в ext2 / ext3 / ext4, которые останавливают даже root, а также предотвращают переименования файлов и т. д
• сетевые файловые системы, где сервер может осуществлять собственный контроль доступа, например, root_squashв NFS сопоставляет root никому
• ПРЕДОХРАНИТЕЛЬ, который, я полагаю, мог сделать что угодно
• монтируемые только для чтения
• устройства только для чтения

Точно так же, как вы заметили для разрешений по умолчанию:

• Чтение и запись:
  по умолчанию пользователь root может получить доступ к любому файлу в системе. Вы можете удалить этот доступ, изменив атрибуты, такие как объяснение здесь: chattr . Это тогда связано с возможностями.

• Выполнить:
  пользователь root не имеет разрешения на выполнение, если не установлен хотя бы один из битов выполнения.

myFile.txtПолучается chmod 000 myFile.txt.

0 no permission
1 execute
2 write
3 execute + write
4 read 
5 read + execute
6 read + write
7 all

--------- означает, что нет разрешения для пользователя, группы и других.

Пользователь root имеет неограниченную возможность изменять этот файл. Чтение / запись предоставляется. Чтобы запустить этот файл, пользователь root должен сделать его исполняемым в любом случае. (chmod 100, 010 или 001)

Режим выполнения обрабатывается немного иначе, чем в других режимах.

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

Разрешение на выполнение - это скорее рекомендательный режим, позволяющий определить, предназначен ли файл для выполнения или является просто данными. Из-за этого даже пользователь root подчиняется ему - нет смысла выполнять файл данных. Если ни одно из прав доступа не установлено, root не может выполнить файл; если любой из них установлен, он может. Конечно, поскольку root также имеет право изменять права доступа к любому файлу, учетная запись может сделать файл исполняемым, если он этого хочет (если файловая система доступна только для чтения).

Кстати, сценарии - интересный случай в этом. Скрипты - это файлы данных для соответствующего переводчика. Если в сценарии есть #!строка, вы можете выполнить ее как программу - интерпретатор, названный в shebang, запускается с именем файла сценария в качестве аргумента. Но это будет сделано только когда установлено разрешение на выполнение. С другой стороны, вы можете просто запустить интерпретатор напрямую, например /bin/bash scriptname. Интерпретаторы заботятся только о том, могут ли они прочитать файл, они не проверяют разрешения на выполнение.

Позвольте мне объяснить вам теоретически.

Пользователь root - король операционной системы.

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

Всегда помните, в Linux root может делать все что угодно, ограничений для root нет.