Флаги в линукс это

Обновлено: 24.01.2025

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

Так, файловые системы ext2/ext3/ext4 управляются специальными атрибутами-флагами, например a (append only), i (immutable), s (secure deletion), S (synchronous updates) и np.

Флаг s заставляет файловую систему при удалении файла не только высвобождать принадлежащие ему блоки, но и обнулять их, а флаг S заставляет операции записи в файл выполняться синхронно (немедленно), минуя отложенную запись с использованием дискового кэша.

Флаг i делает файл «неприкасаемым» — его нельзя ни изменить, ни удалить никому, даже суперпользователю root. Флаг а делает файл «накопительным», т. е. никому не дает изменять имеющуюся в файле информацию или удалять файл, а позволяет только добавлять данные в его конец.

Устанавливать флаги файлов разрешено их владельцам, а установка отдельных флагов, например а или i, требует определенных привилегий процесса.

Для просмотра флагов файлов предназначена утилита lsattr, а для их изменения — утилита chattr, что иллюстрирует листинг ниже на примере флага i.

Листинг флаги файлов

chattr: Операция не позволяется while setting flags on README.mike

-bash: README.mike: Операция не позволяется

rm: невозможно удалить «README.mike»: Операция не позволяется

rm: невозможно удалить «README.mike»: Операция не позволяется!

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

Специальные файлы устройств, именованные каналы и сокеты имеют файловую при

роду и могут обрабатываться совершенно «обычными» программами за счет идентичности их файлового программного интерфейса, наравне с файлами «обычных» (дисковых), сетевых, псевдофайловых и внеядерных файловых систем.

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

У каждого файла имеется определённый набор свойств в файловой системе. Например, это права доступа, владелец, имя, метки времени. В Linux каждый файл имеет довольно много свойств, например, права доступа устанавливаются трижды (для владельца, группы и всех прочих), метки времени также бывают трёх разных видов (время создание, доступа и изменения).

Часть свойств файлов в текущей директории можно посмотреть командой:

Пример свойств одного из файлов:

При этом свойства файла не нужно путать с метаданными. Метаданные — это та информация, которая хранится в самом файле независимо от файловой системы. А свойства файла специфичны для файловой системы и могут быть потеряны, например, при переносе файла из файловой системы EXT4 в NTFS некоторые свойства файла (например, права доступа или метки времени) будут потеряны по той причине, что файловая система NTFS их не поддерживает.

Смотрите также:

Пользователи Linux обычно в курсе режимов доступа к файлам, подробнее о них смотрите в статье «Азы работы в командной строке Linux (часть 6)». Но файлам и директориям могут быть установлены атрибуты, о которы помнят далеко не все пользователи. Именно файловым атрибутам, а также утилитам для установления и считывания файловых атрибутов посвящена данная статья.

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

Список файловых атрибутов в Linux

Различают следующие виды расширенных атрибутов.

Файл с установленным атрибутом «a» можно открыть только в режиме добавления для записи. Только суперпользователь или процесс, обладающий возможностью CAP_LINUX_IMMUTABLE, может установить или очистить этот атрибут.

При доступе к файлу с установленным атрибутом «A» его запись atime не изменяется. Это позволяет избежать определённого количества дисковых операций ввода-вывода для портативных систем.

Файл с установленным атрибутом «c» автоматически сжимается на диске ядром. При чтении из этого файла возвращаются несжатые данные. Запись в этот файл сжимает данные перед их сохранением на диске. Примечание: обязательно прочтите об ошибках и ограничениях в конце этого раздела. (Примечание: для btrfs: если установлен флаг «c», то нельзя установить флаг «C». Также конфликтует с параметром монтирования btrfs «nodatasum»)

Файл с установленным атрибутом «C» не подлежит обновлению «копирование при записи». Этот флаг поддерживается только в файловых системах, которые выполняют копирование при записи. (Примечание: для btrfs флаг «C» должен быть установлен для новых или пустых файлов. Если он установлен для файла, который уже имеет блоки данных, он не определён, когда блоки, назначенные файлу, будут полностью стабильными. Если для каталога установлен флаг «C», он не повлияет на каталог, но для новых файлов, созданных в этом каталоге, будет установлен атрибут No_COW. Если установлен флаг «C», то флаг «c» не может быть установлен. установленный.)

Файл с установленным атрибутом «d» не является кандидатом для резервного копирования при запуске программы dump.

При изменении каталога с установленным атрибутом «D» изменения синхронно записываются на диск; это эквивалентно опции монтирования dirsync, применяемой к подмножеству файлов.

Атрибут «e» указывает, что файл использует экстенты для отображения блоков на диске. Его нельзя удалить с помощью chattr.

Файл, каталог или символическая ссылка с установленным атрибутом «E» зашифрованы файловой системой. Этот атрибут нельзя установить или сбросить с помощью chattr, хотя он может быть отображён с помощью lsattr.

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

Файл с атрибутом «i» не может быть изменён: его нельзя удалить или переименовать, нельзя создать ссылку на этот файл, большую часть метаданных файла нельзя изменить, и файл нельзя открыть в режиме записи. Только суперпользователь или процесс, обладающий возможностью CAP_LINUX_IMMUTABLE, может установить или очистить этот атрибут.

Атрибут «I» используется кодом htree, чтобы указать, что каталог индексируется с использованием хешированных деревьев. Его нельзя установить или очистить с помощью chattr, хотя его можно отобразить с помощью lsattr.

Файл с атрибутом «j» имеет все данные, записанные в журнал ext3 или ext4 перед записью в сам файл, если файловая система смонтирована с параметрами «data=ordered» или «data=writeback» и файловая система имеет журнал. Если файловая система смонтирована с параметром «data=journal», все данные файла уже занесены в журнал, и этот атрибут не действует. Только суперпользователь или процесс, обладающий возможностью CAP_SYS_RESOURCE, может установить или очистить этот атрибут.

Файл с атрибутом «m» исключается из сжатия в файловых системах, которые поддерживают сжатие файлов.

Файл с установленным атрибутом «N» указывает, что файл содержит данные, хранящиеся внутри самого inode. Его нельзя установить или очистить с помощью chattr, хотя его можно отобразить с помощью lsattr.

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

Когда файл с установленным атрибутом «s» удаляется, его блоки обнуляются и записываются обратно на диск. Примечание: обязательно прочтите об ошибках и ограничениях в конце этого раздела.

При изменении файла с установленным атрибутом «S» изменения синхронно записываются на диск; это эквивалентно опции монтирования «sync», применяемой к подмножеству файлов.

Файл с атрибутом «t» не будет иметь фрагмент частичного блока в конце файла, объединённого с другими файлами (для тех файловых систем, которые поддерживают объединение хвостов).

Это необходимо для таких приложений, как LILO, которые читают файловую систему напрямую и не понимают файлы с хвостовым слиянием. Примечание. На момент написания этой статьи файловые системы ext2, ext3 и ext4 не поддерживают слияние хвостов.

Директория с атрибутом «T» будет считаться вершиной иерархии каталогов для целей распределителя блоков Орлова. Это подсказка распределителю блоков, используемому ext3 и ext4, что подкаталоги в этом каталоге не связаны и, следовательно, должны быть разделены для целей распределения. Например, очень хорошая идея установить атрибут «T» в каталоге /home, чтобы /home/john и /home/mary были помещены в отдельные группы блоков. Для каталогов, где этот атрибут не установлен, распределитель блоков Орлова будет пытаться сгруппировать подкаталоги ближе друг к другу, где это возможно.

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

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

Для файла с установленным атрибутом «V» включена функция проверки подлинности. Он не может быть записан, и файловая система будет автоматически проверять все данные, считанные из неё, по криптографическому хешу, который покрывает всё содержимое файла, например через дерево Меркла. Это позволяет эффективно аутентифицировать файл. Этот атрибут нельзя установить или сбросить с помощью chattr, хотя он может быть отображён с помощью lsattr.

Можно ещё вспомнить липкий бит (sticky bit), суть которого в том, что файл с данным битом может удалить только тот пользователь, который является владельцем файла. Липкий бит устанавливается с помощью программы chmod:

Но к рассматриваемым файловым параметрам липкий бит не имеет отношения.

Ошибки и ограничения

Атрибуты «c», «s» и «u» не поддерживаются файловыми системами ext2, ext3 и ext4, как это реализовано в текущих основных ядрах Linux. Установка атрибутов «a» и «i» не повлияет на возможность записи в уже существующие файловые дескрипторы.

Параметр «j» полезен только для файловых систем ext3 и ext4.

Параметр «D» полезен только в ядре Linux 2.5.19 и новее.

chattr — программа для установки и изменения файловых атрибутов

chattr изменяет атрибуты файлов в файловой системе Linux.

Формат символьного режима: +-=[aAcCdDeFijmPsStTux].

Оператор «+» вызывает добавление выбранных атрибутов к существующим атрибутам файлов; «-» заставляет их удалить; и «=» делает их единственными атрибутами файлов.

Буквы «aAcCdDeFijmPsStTux» выбирают новые атрибуты для файлов:

только добавление (a),
без обновлений времени (A),
сжатие (c),
без копирования при записи (C),
без дампа (d),
синхронные обновления каталогов (D),
формат экстента (e),
поиск в каталогах без учёта регистра (F),
неизменяемый (i),
ведение журнала данных (j),
без сжатия (m),
иерархия проекта (P),
безопасное удаление (s),
синхронные обновления (S),
без слияния хвостов (t),
вершина иерархии каталогов (T),
возможность восстановления после удаления (u)
и прямой доступ к файлам (x).

Следующие атрибуты доступны только для чтения и могут быть перечислены lsattr, но не могут быть изменены chattr:

Не все флаги поддерживаются или используются всеми файловыми системами; обратитесь к страницам руководства, относящимся к файловым системам, таким как btrfs, ext4 и xfs для получения дополнительных сведений о файловых системах.

Следующая команда сделает файл test.txt заблокированным для удаления, изменения, перемещения (i):

Причём даже добавление sudo к командам удаления и перемещения не поможет, этот файл будет невозможно изменить и удалить до тех пор, пока не будет удалён атрибут «i».

Смотрите также: Что такое sudo

Следующая команда удаляет атрибут «i»:

Если в качестве цели изменения параметров вы выбрали директории, то опция -R сделает так, что атрибуты будут рекурсивно изменены и для содержимого директорий.

lsattr — программа для показа атрибутов файлов в файловой системе Linux

lsattr перечисляет атрибуты файлов в файловой системе Linux.

Для просмотра файловых атрибутов укажите имя файлов:

-R

Рекурсивный список атрибутов директорий и их содержимого.

-a

Перечислить все файлы в каталогах, включая файлы, начинающиеся с «.».

-d

Список каталогов как и других файлов, а не их содержимое.

-l

Печатать параметры, используя длинные имена вместо односимвольных сокращений.

Кроме уже рассмотренных атрибутов (владелец, группа, "права доступа"), существует еще один атрибут, который ограничивает возможные действия с файлом - "набор флагов".

Кстати, по умолчанию команда ls флаги не показывает (и большинство "коммандеров"/"файлменеджеров" - тоже). Для того, чтобы она их показала, надо указать ключ -lo .

С помощью флагов можно запретить изменять содержимое файла, его название или и то и другое.

Флаги являются более "сильнодействующим средством" чем permissions. Они действуют одинаково для всех юзеров, не разделяя их на категории. Более того, их действие не может игнорировать и владелец файла и даже root. Единственное отличие владельца и root'а от прочих пользователей в том, что они могут убрать флаги с файла (и то не всегда) и только потом уже делать то, что им хочется.

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

На самом деле, "снятие" флагов - вопрос более сложный. Он зависит от того, в каком "режиме безопасности" находится система. Но об этом немного позднее.

append - разрешается только "дописывать" файл (естественно, файл должен также иметь permssion "w"). Без этого флага, если юзеру из соответствующей категории разрешается писать в файл, он может как добавить что-либо к содержимому файла, так и "убавить", то есть стереть часть содержимого. При установленном флаге append, любой юзер (даже root) сможет только добавить что-нибудь в конец файла, но не сможет ничего изменить в уже имеющемся содержимом.
Если этот флаг поставить на директорию, то в ней можно создавать файлы (или копировать туда файлы из других директорий), но нельзя удалять или менять их названия. Естественно, на сами файлы действие флага не распространяется.
nounlink - файл (или директорию) нельзя удалить или переименовать, даже если права, установленные на директории (в которой находится файл) это позволяют. В то же время, этот флаг не запрещает менять содержимое файла (если, конечно, permissions это позволяют).
immutable или change - "ничего нельзя" :-). То есть, файл (директорию) нельзя ни удалить, ни переименовать, ни изменить содержимое. Опять же, если это флаг стоит на директории, то на файлы (в ней содержащиеся) его действие не распространяется. То есть, вы не сможете ни добавить, ни убрать файл в директории, но менять содержимое самих файлов это флаг не запретит.

три "юзерских" - uappend, uunlink и uimmutable
и три "суперюзерских" - sappend, sunlink и simmutable .

archived (архивный файл) - это файл "суперюзерский", то есть его может поставить только root, а аналогичного "юзерского" не существует;
nodump (файл не надо "дампировать") - а это "юзерский" флаг, его может поставить не только root, но и владелец файла.

Эти флаги проверяются только некоторыми конкретными программами. Флаг nodump сообщает программе dump , что этот файл не надо сохранять в архиве. (Подробнее о программе dump вы можете прочитать в соответствующем man'уале - man dump ).

Кем и для чего проверяется флаг archived , я, к сожалению, не знаю.

-1 - система безопасности выключена
0 - система безопасности включена, но никаких ограничений нет
1 - "режим безопасности", установлен ряд ограничений на работу с внешними устройствами и операции с флагами
2 - "повышенная безопасность", еще больше ограничений, чем на уровне 1.

Подробнее о том, в чем заключаются ограничения и как меняются "уровни безопасности", можно прочитать в man ini t (отмечу только, что "по умолчанию" система стартует с уровнем -1, то есть "безопасность" выключена).

Для нас в данный момент важно только, что на уровне 1 и 2, даже суперюзеру (root'у) запрещено снимать флаги sappend и simmutable .

Естественно, это делается не для того, чтобы "защитить" систему от собственного администратора. Он все равно, при желании, сможет убрать эти флаги (и удалить/изменить соответствующие файлы). Правда, для этого ему придется перезагрузить систему, причем с консоли.

А вот "взломщик", проникший в систему, даже если каким-то образом и получит root'овские права, не сможет изменить "жизненно важные файлы" (если, конечно, они защищены флагом simmutable ) или "почистить логи" (если они защищены флагом sappend ), чтобы "замести следы" своего пребывания в системе.

Pluggable Authentication Modules (PAM)

Программы, предоставляющие пользователям привилегии должны правильно идентифицировать каждого пользователя. Когда вы входите в систему, вы предоставляете ваше имя пользователя (username) и пароль (password), и процесс регистрации использует эти данные для проверки: действительно ли вы тот, за кого себя выдаете. Возможны формы проверки подлинности отличные от паролей, и пароли могут храниться разными способами.

Pluggable Authentication Modules (PAM) - это способ, позволяющий системному администратору задавать правила аутентификации без перекомпиляции программ аутентификации. Используя PAM, вы настраиваете определенные модули, включаемые в программу, редактируя конфигурационный PAM файл программы в /etc/pam.d.

Большинство пользователей Red Hat Linux никогда не нуждаются в изменении конфигурационных PAM файлов их программ. Когда вы используете RPM для установки программ, требующих аутентификации, они автоматически вносят необходимые для нормальной работы изменения. Однако, если вам понадобится изменить вашу конфигурацию, вы должны понимать стуктуру конфигурационного файла PAM. Больше информации вы можете найти в разделе "модули PAM".

Преимущества PAM

Общая схема аутентификации, которая может быть использована многими приложениями.
С PAM могуть работать разнообразные приложения, которые не нуждаются в перекомпиляции для поддержки PAM.
Невероятная гибкость управления аутентификацией для администраторов и разработчиков ПО.
Разработчикам не нужно привязывать свои приложения к конкретной схеме аутентификации. Вместо этого они могут сосредоточиться непосредственно на разработке самого приложения.

Конфигурационные файлы PAM.

Каталог /etc/pam.d содержит в себе конфигурационные файлы PAM. В ранних версиях PAM использовался файл pam.conf. Этот файл будет использоваться если не было найдено каталога /etc/pam.d, однако его использование нежелательно.

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

Имена сервисов PAM.

Имя сервиса каждого приложения использующего PAM - это имя его файла конфигурации в /etc/pam.d. Каждое приложение, использующее PAM определяет собственное имя сервиса.

Например, программа login определяет имя login, программа ftpd - ftpd, и так далее.

В общем, имя сервиса - это имя программы использующей сервис, а не программы его предоставляющей.

Модули PAM.

Auth модуль предоставляет фактичкескую аутентификацию (возможно запрашивает и проверяет пароль) и устанавливает удостоверения (credentials) такие как членство в группе или Kerberos tickets.
Account модуль проверяет, разрешена ли регистрация данного пользователя в данный момент (не истекло ли время дествия аккаунта, разрешено ли пользователю регистрироваться в данный момент и т. п.)
Password модуль используется для установки паролей пользователя.
Session модуль используется после того как пользователь прошел регистрацию. Этот модуль позволяет использовать кому-то его аккаунт (например, монтировать домашний каталог пользователя или делать доступным его почтовый ящик).

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

Например, xlogin обычно использует как минимум четыре метода аутентификации, так может выглядеть его конфигурационный файл PAM:

Прежде, чем кто-либо получит доступ к xlogin, PAM проверит отсутствие /etc/nologin, что это не попытка удаленной регистрации под root, и что ни одной переменной окружения не может быть загружено. Затем необходимо успешное выполнение аутентификации xhosts, для того, чтобы позволить установить соединение. Если аутентификация xhosts завершается неудачей, то выполняется стандартная password аутентификация.

Новые PAM модули могут добавляться в любое время, после чего приложения использующие PAM могут работать с ними. Например, если вы создаете one-time-password creation метод и пишете PAM модуль для его поддержки, ваши программы могут сразу его использовать, не требуя перекомпиляции либо других изменений. Как вы уже заметили, это очень полезно, потому как вы можете легко выбирать необходимы компонеты, смешивать их и довольно легко отлаживать получившееся. Методы аутентификации для любых программ можно строить легко и быстро, и у вас нет необходимости перекомпилировать программу или нвосить в нее изменения другого рода.

Документацию касательно написания модулей вы можете найти в /usr/share/doc/pam?(version-number).

Флаги управления PAM.

Каждый модуль PAM возвращает результат успешного выполнения или неудачи. Флаги управления говорят PAM, что нужно делать с результатом. Когда модули расположены в определенной последовательности, флаги дают вам возможность установить "важность" модуля по отношению к следующему за ним.

Вернемся к нашему конфигурационному файлу PAM для xlogin:

Четыре типа флагов, стандартных для PAM.

required. Такой модуль должен быть успешно пройден. Лишь только в этом случае пользователь будет допущен к проверке следующим модулем.
requisite. Чтобы получить аутентификацию, этот модуль должен также быть успешно пройден. Однако, если requisite модуль не будет пройден, управление передается непосредственно приложению.
sufficient. При проверке, завершившейся неудачей, этот модуль будет просто проигнорирован. Но, если sufficient модуль успешно пройден, и не было неудач при прохождение вышестоящих required модулей, то все остальные модули этого типа больше не будут рассматриваться и будут считаться успешно пройденными.
optional. Успешное или неудачное прохождение модулей этого типа не является критичным для общей картины аутентификации. Модули этого типа играют роль только тогда, когда нет модулей других типов.

В настоящий момент в PAM доступны новые флаги управления. Смотрите документацию PAM в /usr/share/doc/pam?(version-number) для получения информации.

Пути к PAM модулям.

Пути к модулям говорят PAM, где искать подключаемый модуль. Обычно, это представляет собой полный путь к модулю, такой как /lib/security/pam_stack.so. Если путь к модулю не будет указан (или он начинается не с '/', то по-умолчанию считается, что модуль расположен в /lib/security.

Аргументы PAM.

PAM использует аргументы для передачи информации подключаемому модулю во время аутентификации. Аргументы позволяют в различных конфигурационных файлах PAM использовать модули по-разному.

Например, модуль pam_userdb.so использует информацию хранящуюся в файле Berkeley DB для аутентификации пользователя. Этому модулю нужно передать аргумент, определяющий имя используемого файла, который у каждого сервиса свой.

Таким образом, строка pam_userdb.so будет выглядеть следующим образом:

auth required /lib/security/pam_userdb.so db=path/to/file

Неправильные аргументы будут проигнорированы и модуль не вернет никакого результата. Когда встречается неверный аргумент, ошибка обычно фиксируется в /var/log/mesages.

Примеры конфигурационного файла PAM.

Конфигурационный PAM файл приложения может выглядеть так:

auth required /lib/security/pam_securetty.so

Вторая строка проверяет наличие терминала с которого производится попытка а аутентификации в файле /etc/securetty, если таковой существует, в случае root логина. Если tty не указан в файле, то аутентификация не будет разрешена.

auth required /lib/security/pam_unix.so shadow nullok

Третья строка запрашивает у пользователя пароль и проверяет его.

auth required /lib/security/pam_nologin.so

Четвертая строка проверяет наличие файла /etc/nologin. Если файл существует и пользоваетль не является root, аутентификация завершится неудачей.

Заметьте, что все три auth модуля будут обрабатываться одниаково, независимо от того, проход какого модуля завершится неудачей. Такая стратегия не позволяет узнать пользователю какой именно этап аутентификации он не прошел. Знание причин провала аутентификации может стать причиной обхода пользователем этого этапа в следующий раз. Вы можете изменить такое поведение системы, заменив required модуль на requisite. Если какой либо requisite модуль не будет пройден, PAM остановится немедленно и вернет результат неудачи. Остальные существующие модули при этом проверяться не будут.

account required /lib/security/pam_unix.so

Пятая строка производит необходимые проверки аккаунта. Например, если включены теневые пароли, модуль pam_unix.so проверяет время действия аккаунта или своевременную смену пароля пользователем.

account required /lib/security/pam_cracklib.so

Шестая строка проверяет, не могут ли измененные пароли быть взломаны при помощи программ перебирающих по словарю.

password required /lib/security/pam_unix.so shadow nullok use_authtok

Седьмая строка определяет, что если программа login изменяет пароль пользователя, она для этого использует модуль pam_unix.so. Это может произойти, если auth модуль определит, что пароль необходимо сменить - например, если истек срок действия пароля.

Восьмая, и последняя строка определяет, что модуль pam_unix.so будет управлять сеансом (сессией). В данный момент этот модуль ничего не делает; он должен быть заменен на необходимый модуль или дополнен stack'ингом (поправьте меня, кто может).

Обратите внимание на порядок строк в файле. Порядок вызова required модулей не имеет значения, доступны другие флаги управления. Использование в файле optional модулей обуславливает важность порядка выполнения модулей sufficient и requisite.

В качестве следующегь примера рассмотрим конфигурационный файл для rlogin:

Первое. Если существует файл /etc/nologin, никто кроме root не сможет зарегистрироваться в системе.

auth required /lib/security/pam_securetty.so

Второе. pam_securetty.so предотвращает регистрацию root с ненадежных терминалов. Неплохо было бы запретить логиниться root'у при помощи rlogin. Если вы желаете иметь такую возможность (в этом случае вы должны иметь хороший firewall или быть отключенным от интернета), смотрите документацию rlogin.

auth required /lib/security/pam_env.so

Третье. Модуль pam_env.so загружает переменные окружения, описанные в /etc/security/pam_env.conf.

auth sufficient /lib/security/pam_rhosts_auth.so

Четвертое. Если pam_rhosts_auth.so аутентифицирует пользователя используя .rhosts в домашнем каталоге пользователя, PAM передает управление непосредственно rlogin, не переходя к следующему шагу аутентификации (обычной проверки пароля). Если проход модуля pam_rhosts_auth.so завершится неудачей, то будет производиться нормальная проверка пароля (следующий шаг).

auth required /lib/security/pam_stack.so service=system-auth

Пятое. Если pam_rhosts_auth.so не был пройден, pam_stack.so с аргументом service=system-auth производит стандартную password аутентификацию.

NOTE:
Если вы не хотите запрашивать пароль в случае неудачной проверки securetty и определения попытки установления удаленного соединения, вы можете сменить pam_securetty.so с required на requisite. Как вариант, вы можете пожелать разрешить удаленные root регистрации, но это не является хорошей идеей.

Источник:
Red Hat Linux 7.1: The Official Red Hat Linux Reference Guide
Перевод:
Александр Шепетко

Читайте также: