xinetd.conf

title: xinetd.conf(5)

summary: файл с настройками xinetd

text:
# xinetd.conf(5)

## ИМЯ
xinetd.conf - файл с настройками xinetd

## ОПИСАНИЕ
xinetd.conf это файл с настройками, который определяет службы, предоставляемые xinetd. Любая строка, у которой первый, не являющийся пробелом символ, это '#' считается строкой с комментарием. Пустые строки игнорируются.

Файл содержит блоки описания служб в виде:

```
service <имя_службы>
{
```

```
<атрибут> <assign_op> <значение> <значение> ...
...
```

```
}
```

Оператор назначения, assign_op, может принимать значения '=', '+=', '-='. Главные атрибуты поддерживают только простой оператор назначения, '='. Атрибуты, которые представляют собой список значений, поддерживают все операторы назначения. Для таких атрибутов '+=' означает добавление значения в список, а '-=' означает удаление значения из списка. Список таких атрибутов будет сформирован после того, как описаны все атрибуты.

Каждый блок задает службу, которая идентифицируется через имя_службы. Далее идет список доступных атрибутов:

id

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

type

Могут быть использованы любые комбинации следующих значений:

RPC

если служба является службой RPC

INTERNAL

если служба предоставляется xinetd.

UNLISTED

если служба не указана в стандартном системном файле (таком как /etc/rpc для служб RPC, или /etc/services для не-RPC служб).

flags

Могут быть использованы любые комбинации следующих флагов:

REUSE

Установить флаг SO_REUSEADDR на сокет службы (смотрите подробности в setsockopt(2) ).

INTERCEPT

Перехватывать пакеты или разрешенные соединения для проверки что они пришли с допустимых адресов (внутренние или многопоточные (multi-thread) службы не могут быть перехвачены).

NORETRY

Не допускать попыток повтора в случае ошибки разветвления (fork).

IDONLY

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

NAMEINARGS

При запуске сервера, заданного в "server", первый аргумент в "server_args" будет argv[0] для сервера. Это позволяет вам использовать tcpd как в обычном inetd, поместив tcpd в "server" и имя сервера в "server_args".

NODELAY

Если служба является tcp-службой и установлен флаг NODELAY, то на сокет службы будет установлен флаг TCP_NODELAY. Если служба не является tcp-службой, то опция не оказывает никакого влияния.

DISABLE

Флаг DISABLE задает службу, которая будет запрещена. Данный флаг перекрывает директиву "enabled", которая включена по умолчанию. Это значит, если вы скажете "enabled = foo", но foo имеет флаг DISABLE, то служба foo не будет запущена. Использование этого флага с директивой службы "disable" не рекомендуется, так как результат непредсказуем.

KEEPALIVE

Если служба является tcp-службой и флаг KEEPALIVE установлен, то на сокет службы будет установлен флаг SO_KEEPALIVE. Если служба не является tcp-службой, то опция не оказывает никакого влияния.

NOLIBWRAP

Флаг зпрещает внутренний вызов библиотеки tcpwrap для определения возможности доступа к службе. Это может понадобится для использования функциональности libwrap недоступной для долгозапускающихся процессов, таких как xinetd; в этом случае, программа tcpd может быть вызвана явно (смотрите флаг NAMEINARGS).

SENSOR

Флаг заменяет службу на сенсор, который служит детектором доступа на заданный порт. ЗАМЕЧАНИЕ: Сенсор НЕ определяет скрытое сканирование. Этот флаг должен использоваться только для служб, которые вам не понадобятся. Когда осуществляет доступ на порт службы, IP адрес добавляется в общий список no_access. Это приводит к тому, что все прочие попытки с этого IP адреса будут запрещены пока не истечет время, устанавливаемое в атрибуте deny_time. Флаг SENSOR также заставляет xinetd установить атрибут server в значение INTERNAL не зависимо от того, что было указано в строке с этим атрибутом. Также важно помнить, что если socket_type установлено в значение stream, то атрибут wait установлен быть не должен.

disable

Принимает значения "yes" или "no". В зависимости от значения служба может быть запрещена и не будет запускаться. Смотрите описание флага DISABLE.

socket_type

Возможные значения этого атрибута включают:

stream

служба основанная на потоках данных

dgram

служба основанная на датаграммах

raw

служба, которая требует прямого доступа к IP

seqpacket

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

protocol

определяет протокол, который обслуживается службой. Этот протокол должен присутствовать в файле /etc/protocols. Если этот атрибут не задан, то службой будет исплользован протокол по умолчанию.

wait

Этот атрибут отпределят, является ли служба однопоточная (single-threaded) или многопоточная (multi-threaded). Если значение атрибута yes, то служба однопоточная; это означает, что xinetd будет запускать сервер службы и затем не будет управлять запросами к этой службе пока сервер не завершит свою работу. Если атрибут имеет значение no, то служба считается многопоточной и xinetd будет продолжать управлять запросами к службе.

user

задает uid для серверного процесса. Пользователь с заданным uid должен сушествовать в /etc/passwd. Данный атрибут неэффективен, если эффективный ID пользователя xinetd не является ID суперпользователя.

group

задает gid для серверного процесса. Группа с заданным gid должна существовать в /etc/group. Если группа не задана, будет использована группа пользователя user (взятая из /etc/passwd). Данный атрибут неэффективен, если эффективный ID пользователя xinetd не является ID суперпользователя.

instances

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

nice

задает приоритет сервера. Это значение является числом (возможно отрицательным); смотрите подробности в nice(3).

server

определяет программу для запуска службы.

server_args

определяет аргументы, передаваемые серверу. В отличие от inetd, имя сервера не включается в server_args.

only_from

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

a)

числовой адрес в форме %d.%d.%d.%d. Если правый компоненты это 0, то они считаются шаблонами (например, 128.138.12.0 означает все узлы подсети 128.138.12). 0.0.0.0 означает все Интернет адреса.

b)

факторизованные адреса в виде %d.%d.%d.{%d,%d,...}. Нет необходимости указывать все 4 компонента (т.е. %d.%d.{%d,%d,...%d} также правильно). Однако, факторизованная часть должна идти в конце адреса.

c)

имя сети (из файла /etc/networks)

d)

имя узла. Когда осуществляется соединение с xinetd, выполняется обратный поиск (имени по адресу -- прим. пер.) и полученное в результате поиска каноническое имя сравнивается с заданным именем узла. Вы можете также использовать имена доменов в виде .domain.com. Если обратный поиск показал, что узел с клиентским IP находится внтури .domain.com, узел попадет под правило.

e)

Диапазон адресов в виде IP адрес/маска, например 1.2.3.4/32.

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

no_access

определяет удаленные узлы для которых указанная служба будет недоступна. Значение этого аргумента может быть задано несколькими способами, также как и значение атрибута only_from. Эти два атрибута определяют как xinetd будет управлять доступом к службе с удаленных адресов. Если для службы не задан ни один из двух атрибутов, то служба будет доступна всем. Если заданы оба атрибута, то доступность службы определяет тот, который лучше совпадает с адресом удаленного узла (например, если список only_from содержит 128.138.209.0 а список no_access содержит 128.138.209.10, то узел с адресом 128.138.209.10 не будет иметь доступа к службе).

access_times

задает временные интервалы в течении которых служба будет доступна. Интервал должен быть в виде hour:min-hour:min (соединения будут доступны внтури этого интервала). Часы могут быть в дипазоне от 0 до 23, а минуты от 0 до 59.

log_type

определяет, куда будет осуществляться протоколирование вывода, осуществляемого сервером службы. Существует два формата:

SYSLOG syslog_facility [syslog_level]

Вывод будет отправляться к syslog с заданным facility. Возможными значениями facility являются: daemon, auth, authpriv, user, local0-7. Возможные имена уровней включают: emerg, alert, crit, err, warning, notice, info, debug. Если уровень не задан, то сообщения будут записываться с уровнем info.

FILE файл [soft_limit [hard_limit]]

Вывод будет добавляться в файл, который будет создан, если он не существует. Дополнительно могут быть заданы два ограничения на размер файла. Первое ограничение является мягким; xinetd будет протоколировать сообщение первое время, когда лимит исчерпается (если xinetd протоколирует в syslog, то сообщение будет отправлено с уровнем приоритета alert ). Второе ограничение является жестким; xinetd будет останавливать протоколирование для соответствующей службы (если это обычный файл, то может быть остановлено протоколирование по нескольким службам) и если протоколирование осуществляется в syslog, то сообщение будет отправлено с уровнем приоритета alert ). Если жесткое ограничение не задано, то по умочанию оно равняется мягкому ограничению плюс 1%, но дополнительный размер не должен выходить за переделы параметров LOG_EXTRA_MIN и LOG_EXTRA_MAX которые по умолчанию установлены в 5K и 20K соответственно (эти константы задаются в config.h).

log_on_success

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

PID

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

HOST

протоколировать адрес удаленного узла

USERID

протоколировать идентификатор удаленного пользователя, используя протокол идентификации RFC 1413. Данная опция доступна только для многопотоковых служб.

EXIT

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

DURATION

протоколировать продолжительность сессии службы

log_on_failure

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

HOST

протоколировать адрес узла.

USERID

протоколировать идентификатор удаленного пользователя, используя протокол идентификации RFC 1413. Данная опция доступна только для многопотоковых служб.

ATTEMPT

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

RECORD

записывать информацию от удаленной стороны в случае, когда сервер не был запущен. Это позволяет отслеживать попытки использования заданной службы. Например, служба login протоколирует локального пользователя, удаленного пользователя и тип терминала. Вот список служб, которые поддерживают эту опцию в данный момент: login, shell, exec, finger.

rpc_version

определяет версию RPC для службы RPC. Эта версия может быть одной цифрой или диапазоном в виде число-число.

rpc_number

определяет количество для службы RPC UNLISTED (данный атрибут игнорируется если служба не является unlisted).

env

Значение этого атрибута - это список строк в виде 'name=value'. Данные строки будут добавлены к окружению перед запуском сервера (таким образом окружение сервера будет включать окружение xinetd плюс заданные строки).

passenv

Значение этого атрибута - это список переменных окружения из окружения xinetd которые будут переданы серверу. Пустой список неявно означает серверу не будет передано никаких переменных за исключением тех, которые явно заданы атрибутом env. (заметим что вы можете использовать данный атрибут совместо с атрибутом env чтобы задать для передачи серверу точно те аргументы, которые нужны).

port

задает порт службы. Если этот атрибут задается для службы, указанной в /etc/services, он должен быть таким же как и порт в этом файле.

redirect

Позволяет перенаправить службу tcp на другой узел. Когда xinetd получает tcp соединение на этот порт, вызывается процесс, который устанавливает соединение к указанному узлу и номеру порта и который пересылает все данные между двумя узлами. Данная опция полезна, когда ваши внутренние машины не видны снаружи. Ситаксис такой: redirect = (ip адрес) (порт). Вы также можете использовать в данном поле имя узла, вместо IP адреса. Поиск адреса по имени узла выполняется только один раз, когда xinetd запускается и пока xinetd не будет перезапущен будет использован первый IP адрес, возвращенный при этом поиске. Атрибут "server" при задании этой опции не требуется. Если же атрибут "server" задан, то он имеет приоритет.

bind

Позволяет службе привязаться к заданному интерфейсу машины. Это означает, что вы можете получить telnet сервер слушающий на локальном, безопасном интерфейсе, а не на внешнем. Или на порте, на одном интерфейсе может висеть что-либо одно и в то же время, на этом же порте, на другом интерфейсе может висеть полностью другое. Синтаксис: bind = (ip адрес интерфейса).

interface

Синоним для bind.

banner

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

banner_success

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

banner_fail

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

per_source

В качестве аргумента указвается число или "UNLIMITED". Задает максимальное количество копий службы на исходный IP адрес. Это может также быть задано в секции настроек по умолчанию.

cps

Ограничение частоты входящих соединений. Имеет два аргумента. Первый аргумент - это количество соединений в секунду. Если частота входящих соединений будет выше, служба будет временно запрещена. Второй аргумент - это количество секунд ожидания перед тем как служба будет разрешена после того как она была запрещена.

max_load

Использует число с плавающей точкой как величину загрузки, при достижении которой служба будет останавливать прием соединений. Например: 2 или 2.5. Служба остановит прием соединений при достижении этой загрузки (load average). Эта особенность зависит от реализации операционной системы и в данный момент поддерживается только на Linux и Solaris.

groups

Может принимать значения "yes" или "no". Если атрибут groups установлен в "yes", то сервер запускается с доступом для групп, к которым имеет доступ эффективный UID сервера. Если атрибут groups установлен в "no", то сервер запускается без дополнительных групп. Данный аттрибут должен быть установлен в "yes" для большинства BSD систем. Данный аттрибут может быть также установлен и в секции настроек по умочанию.

umask

Унаследовать umask для этой службы. Ожидается восьмеричное значение. Данная опция может быть установлена в секции "по умолчанию" для установки umask для всех служб. xinetd устанавливает свои собственные umask на предыдущую umask логически складывая ее с 022. Это umask, которая наследуется всеми процессами-потомками, если не использована опция umask.

enabled

Разрешает список служб. Будут разрешены только те службы, которые перечислены как аргументы данного атрибута; остальные службы будут запрещены. Если у службы установлен атрибут "disable" или флаг "DISABLE", то эта служба разрешена не будет.

include

В качестве аргумента указывается имя файла в виде "include /etc/xinetd/service". Указанный файл затем будет обработан как новый файл с настройками. Это не тоже самое - включить содержимое данного файла в xinetd.conf на место директивы include. Подключаемый файл должен быть в то же виде, что и xinetd.conf. Он должен содержать внутри описание какой-либо службы. Данная директива должна быть вне блока описания службы.

includedir

В качестве аргумента указывается каталог в виде "includedir /etc/xinetd.d". Каждый файл внтури этого каталога, за исключением файлов с именами, содержащими точку ('.') или заканчивающимися на ('~'), будут обработаны как файлы с настройками для xinetd. Файлы будут обработаны в алфавитном порядке, согласно локали C. Это позволяет вам задавать службы по одной на файл внутри каталога. Директива includedir не может находится внутри блока описания службы.

rlimit_as

Устанавливает ограничение ресурса Адресного Пространства для указанной службы. Директива требует один параметр, который является либо положительным целым числом, представляющим собой количество байт, которое определяет ограничение (для задания килобайт/мегабайт могут использоваться K или M) или значение "UNLIMITED". Исходя из способа реализации malloc в Linux libc, данная директива более полезна для установки ограничения, чем rlimit_data, rlimit_rss и rlimit_stack. Ограничение ресурса реализовано только в Linux.

rlimit_cpu

Устанавливает максимальное количество секунд CPU, которое может использовать данная служба. Директива требует один параметр, который должен быть либо целым положительным числом, представляющим количество секунд CPU или значением "UNLIMITED".

rlimit_data

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

rlimit_rss

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

rlimit_stack

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

deny_time

Устанавливает промежуток времени, в который будет запрещен доступ ко всем службам на все IP адреса для тех, у кого сброшен флаг SENSOR. Время указывается в минутах. Допустимы опции: FOREVER, NEVER и числовое значение. FOREVER говорит, что данный IP адрес не будет удален пока xinetd не будет перезапущен. NEVER оказывает влияение только на протоколирование обиженного IP адреса. Обычно значение времени должно быть 60. Это должно остановить большинство DOS атак и в тоже время разрешить IP адреса который приходят из пула для легитимных целей. Данная опция должна использоваться совместо с флагом SENSOR.

Вам не нужно задавать все из данных выше атрибутов для каждой службы. Необходимыми атрибутами для службы являются:

socket_type

user

(только не-internal службы)

server

(только не-internal службы)

wait

protocol

(только службы RPC и unlisted)

rpc_version

(только службы RPC)

rpc_number

(только unlisted RPC службы)

port

(только unlisted не-RPC службы)

Следующие атрибуты поддерживают все операторы назначения:

only_from

no_access

log_on_success

log_on_failure

passenv

env

(не поддерживает оператор '-=' )

Эти атрибуты могут также встречаться более чем один раз в описании службы. Остальные атрибуты поддерживают только оператор '=' и могут встречаться в описании службы не более одного раза.

Файл с настройками может также сожержать одно описание службы по умолчанию в виде

```
defaults
{
```

```
<attribute> = <value> <value> ...
...
```

```
}
```

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

log_type

log_on_success

(накопительный эффект)

log_on_failure

(накопительный эффект)

only_from

(накопительный эффект)

no_access

(накопительный эффект)

passenv

(накопительный эффект)

instances

disabled

(накопительный эффект)

enabled

(накопительный эффект)

Атрибуты с накопительным эффектом могут быть заданы несколько раз, а заданных значения каждый раз складываются (т.е. '=' не тоже самое что '+='). За исключением disabled все эти атрибуты означают тоже самое, как если бы они были заданы в блоке описания службы. disabled определяет службы, которые запрещаются даже если если они описаны в файле с настройками. Это позволяет через задание запрещенных служб в атрибуте disabled произвести быструю перенастройку, вместо того, чтобы комментировать описания служб. Значение этого атробута - это список разделенных пробелами идентификаторов служб. enabled задается также как и disabled. Различие в том, что enabled является списком разрешенных служб. Если задан атрибут enabled то будут разрешены только службы, которые переислены в нем. Если enabled не задан, то будут разрешены все службы, описанные в файле с настройками, за исключением тех, что заданы в атрибуте disabled.

## ВНТУРЕННИЕ СЛУЖБЫ
xinetd предоставляет следующие службы внутренне (основанные как на потоках так и на датаграммах): echo, time, daytime, chargen, и discard. Эти службы имеют такие же ограничения доступа как и все другие службы, за исключением того, что у xinetd нет необходиомости производить разветвление (fork) для них. Также (time, daytime, и основанные на датаграммах echo, chargen и discard) не имеют ограничений по количеству копий.

xinetd также предоставляет две внутренние UNLISTED основанные на потоках службы: servers и services. Первая формирует списки информации о запущенных серверах, а вторая предоставляет список активных в данный момент служб. Информация выдается по одной службе на строку и каждая строка содержит имя службы, протокол (например "tcp") и номер порта.

Также теперь существует административный интерфейс, который является внтуренней службой. Зарезервировано имя службы "xadmin" и эта служба всегда будет внутренней. Вы должны задать номер порта для этой службы и предположительно также какое-нибудь основанное на IP управление доступом, так чтобы в тоже время там не было никаких ограничений по паролю. Вы можете использовать telnet на этот порт и таким образом, по запросу, получать от xinetd какую-нибудь информацию.

## ЗАМЕЧАНИЯ
1.

Следующие атрибуты служб не могут быть изменены или перенастроены: socket_type, wait, protocol, type.

2.

Когда атрибуты only_from и no_access для какой-либо службы не заданы (непосредственно или через defaults) то проверка адреса считается успешной (т.е. доступ запрещен не будет).

3.

Проверка адреса основывается на IP адресе удаленного узла, а не на адресе его домена. Мы сделали так, чтобы мы могли не учитывать поиск удаленного имени по адресу, который может занять много времени (так как xinetd является однопоточным, поиск имени приведет к тому, что демон не сможет обработать другие запросы пока не осуществится поиск). С другой стороны, если IP адрес удаленного узла изменился, то доступ к этому узлу будет запрещен пока xinetd не будет перенастроен. Чтобы доступ не был запрещен независимо от изменения адреса, можно задать сеть. Например, если IP адрес узла изменился с 1.2.3.4 на 1.2.3.5, а only_from задан как 1.2.3.0 то доступ запрещен не будет.

4.

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

5.

Перехват работает через разветвление процесса, который работает как фильтр между удаленным узлом(узлами) и локальным сервером. Такая реализация дает увеличение производительности и вы можете найти для каждой службы компромисс между безопастностью и производельностью. Следующие таблицы показывают overhead перехватов. Первая таблица показывает время overhead-на-датаграмму для службы, основанной на UDP, при использовании разных размеров датаграмм. Для служб, основанных на TCP, мы измеряли уменьшение пропускной способности, потому что перехват происходит во время отправки определенного количества данных от клиента к серверу (время overhead должно быть таким же как и для служб, основанных на UDP, но оно влияет только на первый пакет продолжительной передачи данных). Количество данных дается в таблице как системные_вызовыxотправленные_данные_на_вызов, т.е. как много каждый системный вызов send(2) передает байт данных. Уменьшение пропускной способности дается в терминах байт в секунду и как проценты от пропускной способности, когда перехват не выполняется. Все измерения были выполнены на SparcStation IPC с запущенной SunOS 4.1.

Размер датаграммы (байты)

Время (миллисек)

---------------------

--------------

64

1.19

256

1.51

1024

1.51

4096

3.58

Байт отправлено

Уменьшение пропускной способности

----------

-------------------

10000x64

941 (1.2%)

10000x256

4,231 (1.8%)

10000x1024

319,300 (39.5%)

10000x4096

824,461 (62.1%)

## ПРИМЕР

```
#
# Простой файл с настройками для xinetd
#
defaults
{
```

log_type

```
= FILE /var/log/servicelog
```

log_on_success

```
= PID
```

log_on_failure

```
= HOST RECORD
```

only_from

```
= 128.138.193.0 128.138.204.0 128.138.209.0
```

only_from

```
= 128.138.252.1
```

instances

```
= 10
```

disabled

```
= rstatd
```

```
}
#
# Замечание 1: атрибут protocol не требуется
# Замечание 2: атрибут instances перекрывает установки по умолчанию
#
service login
{
```

socket_type

```
= stream
```

protocol

```
= tcp
```

wait

```
= no
```

user

```
= root
```

server

```
= /usr/etc/in.rlogind
```

instances

```
= UNLIMITED
```

```
}
#
# Замечение 1: атрибут instances перекрывает установки по умолчанию
# Замечение 2: флаги log_on_success прибавляются
#
service shell
{
```

socket_type

```
= stream
```

wait

```
= no
```

user

```
= root
```

instances

```
= UNLIMITED
```

server

```
= /usr/etc/in.rshd
```

log_on_success

```
+= HOST RECORD
```

```
}
service ftp
{
```

socket_type

```
= stream
```

wait

```
= no
```

nice

```
= 10
```

user

```
= root
```

server

```
= /usr/etc/in.ftpd
```

server_args

```
= -l
```

instances

```
= 4
```

log_on_success

```
+= DURATION HOST USERID
```

access_times

```
= 2:00-9:00 12:00-24:00
```

```
}
# Ограничение сессий telnet до 8 мегабайт памяти и 20 секунд процессорного
# времени для дочерних процессов
service telnet
{
```

socket_type

```
= stream
```

wait

```
= no
```

nice

```
= 10
```

user

```
= root
```

server

```
= /usr/etc/in.telnetd
```

rlimit_as

```
= 8M
```

rlimit_cpu

```
= 20
```

```
}
#
# Данный блок описания службы, а также следующий, задают внутренние службы.
# Поскольку та же служба использует другой тип сокета, для создания
# уникальности описания используется разный атрибут id
service echo
{
```

id

```
= echo-stream
```

type

```
= INTERNAL
```

socket_type

```
= stream
```

user

```
= root
```

wait

```
= no
```

```
}
service echo
{
```

id

```
= echo-dgram
```

type

```
= INTERNAL
```

socket_type

```
= dgram
```

user

```
= root
```

wait

```
= no
```

```
}
service servers
{
```

type

```
= INTERNAL UNLISTED
```

protocol

```
= tcp
```

port

```
= 9099
```

socket_type

```
= stream
```

wait

```
= no
```

```
}
#
# Простая служба RPC
#
service rstatd
{
```

type

```
= RPC
```

socket_type

```
= dgram
```

protocol

```
= udp
```

server

```
= /usr/etc/rpc.rstatd
```

wait

```
= yes
```

user

```
= root
```

rpc_version

```
= 2-4
```

env

```
= LD_LIBRARY_PATH=/etc/securelib
```

```
}
#
# Простая служба unlisted
#
service unlisted
{
```

type

```
= UNLISTED
```

socket_type

```
= stream
```

protocol

```
= tcp
```

wait

```
= no
```

server

```
= /home/user/some_server
```

port

```
= 20020
```

```
}
```

```

```

## СМОТРИ ТАКЖЕ
xinetd(1L),

xinetd.log(5)

Postel J., Echo Protocol , RFC 862, May 1983

Postel J., Discard Protocol , RFC 863, May 1983

Postel J., Character Generator Protocol , RFC 864, May 1983

Postel J., Daytime Protocol , RFC 867, May 1983

Postel J., Harrenstien K., Time Protocol , RFC 868, May 1983

StJohns M., Identification Protocol , RFC 1413, February 1993

## ОШИБКИ
Если флаг INTERCEPT не используется, то управление доступом по адресу удаленного узла не осуществляется, когда wait в yes и socket_type в stream.

Если флаг INTERCEPT не используется, то управление доступом по адресу удаленного узла для служб, у которых wait в yes и socket_type в dgram выполняется только на первый пакет. Сервер может затем принимать пакеты от узлов, которых нет в списке управления доступом. Это может происходить со службами RPC.

Не существует способа поместить SPACE в какую-либо переменную окружения.

Когда wait в yes и socket_type в stream, сокет передаваемый серверу может только принимать соединения.

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

## ПЕРЕВОД
Перевод с английского выполнил Виктор Вислобоков <victor_v@permonline.ru>


package: policycoreutils

title: selinux_config(5)

summary: файл конфигурации подсистемы SELinux.

text:
# selinux_config(5)

## ИМЯ
config - файл конфигурации подсистемы SELinux.

## ОПИСАНИЕ
Файл config SELinux управляет состоянием SELinux, определяя:

1.

Состояние применения политики - enforcing (принудительный режим), permissive (разрешительный режим) или disabled (отключена).

2.

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

3.

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

4.

Поведение поддерживающих SELinux приложений при отсутствии настроенных действительных пользователей SELinux.

5.

Следует ли повторно проставлять метки в системе.

Описание записей, которые управляют этими возможностями, приводится в разделе ФОРМАТ ФАЙЛА.

Полный путь к файлу конфигурации SELinux: /etc/selinux/config.

Если файл config отсутствует или повреждён, политика SELinux не будет загружена (то есть SELinux будет отключён).

Команда sestatus (8) и функция libselinux selinux_path (3) возвращают расположение файла config.

## ФОРМАТ ФАЙЛА
Файл config поддерживает следующие параметры:

SELINUX = enforcing | permissive | disabled

SELINUXTYPE = policy_name

REQUIREUSERS = 0 | 1

AUTORELABEL = 0 | 1

Где:

SELINUX

Эта запись может содержать одно из трёх значений: enforcing

Политика безопасности SELinux применяется.

permissive

Политика безопасности SELinux не применяется, но ведётся журналирование предупреждений (то есть действиям разрешено продолжать выполняться).

disabled

SELinux отключён, политика не загружена.

Значение записи можно узнать с помощью команды sestatus(8) или selinux_getenforcemode(3).

SELINUXTYPE

Запись policy_name используется для идентификации типа политики и становится именем каталога, в котором располагаются политика и её файлы конфигурации. Значение записи можно узнать с помощью команды sestatus(8) или selinux_getpolicytype(3).

policy_name относится к пути, который определён внутри подсистемы SELinux и может быть получен с помощью selinux_path(3). Пример записи, полученной с помощью selinux_path(3):

/etc/selinux/

Затем к концу этой записи добавляется policy_name, и она становится корневым расположением политики, которое может быть получено с помощью selinux_policy_root_path(3). Пример полученной записи:

/etc/selinux/targeted

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

/etc/selinux/targeted/policy/policy

По соглашению к концу имени двоичной политики добавляется версия политики SELinux, которую она поддерживает. Максимальную версию политики, поддерживаемую ядром, можно определить с помощью команды sestatus(8) или security_policyvers(3). Пример файла двоичной политики с версией:

/etc/selinux/targeted/policy/policy.24

REQUIRESEUSERS

Эта необязательная запись позволяет сделать попытку входа неудачной, если в файле seusers(5) нет соответствующей записи или записи по умолчанию или отсутствует сам файл seusers. Она проверяется функцией getseuserbyname(3), которая вызывается поддерживающими SELinux приложениями для входа, например, PAM(8).

Если задано значение 0 или отсутствует запись:

getseuserbyname(3) вернёт имя пользователя GNU / Linux в качестве пользователя SELinux.

Если задано значение 1:

getseuserbyname(3) не удастся выполнить.

Описание работы getseuserbyname(3) содержится на соответствующей man-странице. Формат файла seusers показан в seusers(5).

AUTORELABEL

Эта необязательная запись позволяет повторно проставлять метки в файловой системе. Если задано значение 0 и в корневом каталоге имеется файл с именем .autorelabel, при перезагрузке загрузчик перейдёт в оболочку, запрашивающую вход в качестве пользователя root. Затем администратор сможет вручную проставить метки в файловой системе.

Если задано значение 1 или запись отсутствует (состояние по умолчанию) и в корневом каталоге имеется файл .autorelabel, в файловой системе с помощью fixfiles -F restore будут автоматически повторно проставлены метки.

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

## ПРИМЕР
В этом примере показано минимальное содержимое файла config, которое обеспечит запуск SELinux в системе в принудительном режиме, со значением policy_name 'targeted':

SELINUX = enforcing

SELINUXTYPE = targeted

## СМОТРИТЕ ТАКЖЕ
selinux(8), sestatus(8), selinux_path(3), selinux_policy_root_path(3), selinux_binary_policy_path(3), getseuserbyname(3), PAM(8), fixfiles(8), selinux_mkload_policy(3), selinux_getpolicytype(3), security_policyvers(3), selinux_getenforcemode(3), seusers(5)

## АВТОРЫ
Перевод на русский язык выполнила Герасименко Олеся <gammaray@basealt.ru>.


sestatus.conf

title: sestatus.conf(5)

summary: файл конфигурации sestatus(8).

text:
# sestatus.conf(5)

## ИМЯ
sestatus.conf - файл конфигурации sestatus(8).

## ОПИСАНИЕ
Файл sestatus.conf используется командой sestatus(8) с параметром -v, чтобы определить, какие контексты безопасности файлов и процессов следует показать.

Полный путь к файлу конфигурации:

/etc/sestatus.conf

Файл состоит из двух необязательных разделов (описание содержится в разделе ФОРМАТ ФАЙЛА). Независимо от того, существуют ли эти разделы, всегда показывается следующее:

Контекст текущего процесса

Контекст процесса init

Контекст файла управляющего терминала

## ФОРМАТ ФАЙЛА
Формат состоит из двух необязательных разделов (пример далее):

[files]

file_name

[file_name]

... [process]

executable_file_name

[executable_file_name]

...

Где:

[files] Начало блока списка файлов.

file_name Одно или несколько полных имён файлов (каждое на новой строке), контекст которых будет показан. Если файл не существует, он игнорируется. Если файл является символической ссылкой, sestatus -v также покажет контекст целевого файла.

[process]

Начало блока списка процессов.

executable_file_name Одно или несколько полных имён исполняемых файлов; будет показан контекст соответствующих активных процессов. Каждая запись находится на новой строке.

## ПРИМЕР
\# /etc/sestatus.conf

[files]

/etc/passwd

/etc/shadow

/bin/bash

/bin/login

/lib/libc.so.6

/lib/ld-linux.so.2

/lib/ld.so.1

[process]

/sbin/mingetty

/sbin/agetty

/usr/sbin/sshd

## СМОТРИТЕ ТАКЖЕ
selinux(8), sestatus(8)

## СМОТРИТЕ ТАКЖЕ
Перевод на русский язык выполнила Герасименко Олеся <gammaray@basealt.ru>


setrans.conf

package: policycoreutils-mcstransd

title: setrans.conf(5)

text:
# setrans.conf(5)

## ИМЯ
setrans.conf - файл конфигурации преобразования для систем MCS/MLS SELinux

## ОПИСАНИЕ
Файл конфигурации /etc/selinux/{SELINUXTYPE}/setrans.conf определяет способ, которым метки SELinux MCS/MLS преобразовываются в удобную для прочтения человеком форму с помощью внутренней службы mcstransd. Политики по умолчанию поддерживают 16 уровней конфиденциальности (от s0 до s15) и 1024 категории (от c0 до c1023). Если категорий несколько, их можно разделить запятыми (c0,c1,c3,c5), а диапазон категорий - сократить с помощью указания через точку (c0.c3,c5).

### Ключевые слова
Base

когда объявляется база, ко всем последующим определениям меток конфиденциальности будут при преобразовании применяться модификаторы. Метки конфиденциальности, которые были определены до объявления базы, незамедлительно кэшируются, и к ним не применяются модификаторы; они используются в качестве прямого преобразования.

Default

определяет битовый диапазон категорий, который будет использоваться для обратных битов.

Domain

создаёт новый домен с указанным именем.

Include

прочитать и обработать содержимое указанного файла конфигурации.

Join

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

ModifierGroup

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

Prefix

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

Suffix

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

Whitespace

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

### Примеры определения уровня конфиденциальности
s0=SystemLow

определяет преобразование s0 (минимального уровня конфиденциальности) без категорий в SystemLow.

s15:c0.c1023=SystemHigh

определяет преобразование s15:c0.c1023 в SystemHigh. c0.c1023 - сокращённое обозначение всех категорий. Уровень конфиденциальности и категории разделены двоеточием.

s0-s15:c0.c1023=SystemLow-SystemHigh

определяет преобразование диапазона s0-s15:c0.c1023 в SystemLow-SystemHigh. Два компонента диапазона разделены дефисом.

s0:c0=PatientRecord

определяет преобразование уровня конфиденциальности s0 с категорией c0 в PatientRecord.

s0:c1=Accounting

определяет преобразование уровня конфиденциальности s0 с категорией c1 в Accounting.

s2:c1,c2,c3=Confidential3Categories

s2:c1.c3=Confidential3Categories

и то, и другое определяет преобразование уровня конфиденциальности s2 с категориями c1, c2 и c3 в Confidential3Categories.

s5=TopSecret

определяет преобразование уровня конфиденциальности s5 без категорий в TopSecret.

### Примеры ограничения
c0!c1

если одновременно заданы биты категорий 0 и 1, ограничение не сработает и будет возвращён исходный контекст.

c5.c9>c1

если заданы биты категорий с 5 по 9, бит 1 также необходимо установить - иначе ограничение не сработает и будет возвращён исходный контекст.

s1!c5,c9

если заданы биты категорий с 5 по 9 и уровень конфиденциальности равен s1, ограничение не сработает и будет возвращён исходный контекст.

## ФАЙЛЫ
/etc/selinux/{SELINUXTYPE}/setrans.conf

/usr/share/mcstrans/examples

## СМОТРИТЕ ТАКЖЕ
selinux(8), mcs(8), mls(8), chcon(1)

## АВТОРЫ

Написано Joe Nall <joe@nall.com>.

Обновлено Ted X. Toth <txtoth@gmail.com>.

Перевод на русский язык выполнила Герасименко Олеся <gammaray@basealt.ru>.


sandbox

package: policycoreutils-sandbox

title: sandbox(5)

text:
# sandbox(5)

## ИМЯ
sandbox.conf - файл конфигурации пользователей для изолированной среды SELinux

## ОПИСАНИЕ
Если изолированная среда запускается с аргументом -C, она будет ограничена с помощью групп управления. Системный администратор может указать, как именно ограничить изолированную среду.

Весь текст после "#" игнорируется, как и пустые строки. Все аргументы должны быть разделены пробелами и иметь знаки равенства ("=").

Эти ключевые слова разрешены.

NAME

Имя группы управления изолированной средой. По умолчанию: "sandbox".

CPUAFFINITY

Определяет, каким процессорам назначить изолированную среду. По умолчанию она назначается всем процессорам (ALL), но пользователи могут указать разделённый запятыми список с дефисами ("-"), чтобы представить диапазоны. Пример: 0-2,5

MEMUSAGE

Определяет, сколько памяти разрешается использовать изолированной среде. Значение по умолчанию: 80%. Пользователи могут указать либо процентное значение, либо значение в виде числа, за которым следует суффикс K, M, G, для соответствующего обозначения килобайтов, мегабайтов или гигабайтов. Пример: 50% или 100M

CPUUSAGE

Процент использования ЦП, разрешённый для изолированной среды. По умолчанию: 80%. Укажите значение, за которым следует знак процента ("%"). Пример: 50%

## СМОТРИТЕ ТАКЖЕ
sandbox(8)

## АВТОРЫ
Эта страница руководства была написана Thomas Liu <tliu@fedoraproject.org>. Перевод на русский язык выполнила Герасименко Олеся <gammaray@basealt.ru>.


package: sssd

title: sss_rpcidmapd(5)

text:
# sss_rpcidmapd(5)

## NAME
sss_rpcidmapd - инструкции по настройке модуля sss для rpc.idmapd

## ФАЙЛ КОНФИГУРАЦИИ
Файл конфигурации rpc.idmapd обычно находится здесь: /etc/idmapd.conf. Дополнительные сведения доступны на справочной странице idmapd.conf(5).

## РАСШИРЕНИЕ КОНФИГУРАЦИИ SSS

### Включить модуль SSS
В разделе “[Translation]” измените или укажите атрибут “Method”, чтобы он содержал sss.

### Раздел конфигурации [sss]
Чтобы изменить стандартное значение одного из указанных ниже атрибутов конфигурации модуля sss, для него потребуется создать соответствующий раздел конфигурации с именем “[sss]”.

Атрибуты конфигурации

memcache (логическое значение)

Обозначает, следует ли использовать технику оптимизации memcache. По умолчанию: true

## ИНТЕГРАЦИЯ SSSD
Для работы модуля SSS необходимо включить в SSSD ответчик NSS.

Атрибут “use_fully_qualified_names” необходимо включить для всех доменов (клиенты NFSv4 ожидают передачи полного имени «на лету»).

## ПРИМЕР
В следующем примере показан минимальный idmapd.conf, где используется модуль sss.

```
[General]
Verbosity = 2
# домен должен быть синхронизирован между сервером NFSv4 и клиентами
# в Solaris/Illumos/AIX по умолчанию используется «localdomain»!
Domain = default
[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody
[Translation]
Method = sss
```

## СМ. ТАКЖЕ
sssd(8), idmapd.conf(5)

## AUTHORS
Noam Meltzer

Primary Data Inc.

Разработчик (2013—2014)

Noam Meltzer <tsnoam@gmail.com>

Разработчик (2014—)


sssd-session-recording

title: sssd-session-recording(5)

summary: Настройка записи сеансов с помощью SSSD

text:
# sssd-session-recording(5)

## NAME
sssd-session-recording - Настройка записи сеансов с помощью SSSD

## ОПИСАНИЕ
На этой справочной странице представлено описание настройки sssd(8) для работы с tlog-rec-session(8), частью пакета tlog, для реализации записи сеансов пользователей на текстовых терминалах. Подробные сведения о синтаксисе доступны в разделе “ФОРМАТ ФАЙЛА” справочной страницы sssd.conf(5).

SSSD можно настроить на включение записи всего, что определённые пользователи видят или набирают во время сеансов работы на текстовых терминалах. Например, можно записывать данные входа пользователей с помощью терминала или SSH. Сам сервис SSSD ничего не записывает, но обеспечивает запуск tlog-rec-session при входе пользователя, чтобы эта программа вела запись согласно своим параметрам конфигурации.

Для пользователей, для которых включена запись сеансов, SSSD заменяет оболочку пользователя на tlog-rec-session в ответах NSS и добавляет переменную, которая указывает исходную оболочку для среды пользователя, при настройке сеанса PAM. Таким образом обеспечивается запуск tlog-rec-session вместо оболочки пользователя и предоставление данных о том, какую командную оболочку следует запустить после настройки записи.

## ПАРАМЕТРЫ КОНФИГУРАЦИИ
Эти параметры можно использовать для настройки записи сеансов.

scope (строка)

Одна из следующих строк, которые определяют область записи сеанса: «none»

Пользователи не записываются.

«some»

Записываются пользователи и группы, указанные с помощью параметров users и groups.

«all»

Записываются все пользователи.

По умолчанию: «none»

users (строка)

Разделённый запятыми список пользователей, для которых включена запись сеансов. Соответствие списку устанавливается по именам пользователей, возвращённым NSS, то есть после возможной замены пробелов, смены регистра и так далее. По умолчанию: пусто. Не соответствует ни одному пользователю.

groups (строка)

Разделённый запятыми список групп, для участников которых включена запись сеансов. Соответствие списку устанавливается по именам групп, возвращённым NSS, то есть после возможной замены пробелов, смены регистра и так далее. ПРИМЕЧАНИЕ: использование этого параметра (его установка в одно из значений) значительно сказывается на производительности, поскольку при каждом некэшированном запросе данных пользователя требуется выполнить получение и установление соответствия групп, участником которых он является.

По умолчанию: пусто. Не соответствует ни одной группе.

exclude_users (строка)

Разделённый запятыми список пользователей, которые исключаются из записи; применимо только при «scope=all». По умолчанию: пусто. Не исключается ни один пользователь.

exclude_groups (строка)

Разделённый запятыми список групп, участники которых исключаются из записи; применимо только при «scope=all». ПРИМЕЧАНИЕ: использование этого параметра (его установка в одно из значений) значительно сказывается на производительности, поскольку при каждом некэшированном запросе данных пользователя требуется выполнить получение и установление соответствия групп, участником которых он является.

По умолчанию: пусто. Не исключается ни одна группа.

## ПРИМЕР
Следующий фрагмент sssd.conf включает запись сеансов для пользователей «contractor1» и «contractor2», а также группы «students».

```
[session_recording]
scope = some
users = contractor1, contractor2
groups = students
```

## СМ. ТАКЖЕ
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

## AUTHORS
Восходящий источник («апстрим») SSSD — https://github.com/SSSD/sssd/


sssd-sudo

title: sssd-sudo(5)

text:
# sssd-sudo(5)

## NAME
sssd-sudo - Настройка sudo с помощью внутреннего сервера SSSD

## ОПИСАНИЕ
На этой справочной странице представлено описание настройки sudo(8) для работы с sssd(8), а также кэширования правил sudo в SSSD.

## Настройка SUDO для совместной работы с SSSD
Чтобы включить SSSD как источник правил sudo, добавьте sss в запись sudoers в файле nsswitch.conf(5).

Например, чтобы настроить sudo на поиск правил сначала в стандартном файле sudoers(5) (который должен содержать правила, которые применяются к локальным пользователям), а потом в SSSD, следует добавить в файл nsswitch.conf следующую строку:

```
sudoers: files sss
```

Дополнительные сведения о настройке порядка поиска sudoers из файла nsswitch.conf, а также информация о схеме LDAP, используемой для сохранения правил sudo в каталоге, доступны на справочной странице sudoers.ldap(5).

Примечание: чтобы использовать в правилах sudo сетевые группы или группы узлов IPA, также потребуется корректно установить nisdomainname(1) в значение имени домена NIS (совпадает с именем домена IPA в случае использования групп узлов).

## Настройка SSSD для получения правил SUDO
На стороне SSSD достаточно расширить список служб добавлением «sudo» в раздел [sssd] sssd.conf(5). Чтобы ускорить поиск LDAP, также можно указать базу поиска для правил sudo с помощью параметра ldap_sudo_search_base.

В следующем примере показано, как настроить SSSD на загрузку правил sudo с сервера LDAP.

```
[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = EXAMPLE
[domain/EXAMPLE]
id_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
```

Важно учитывать, что на платформах, где поддерживается systemd, не требуется добавлять поставщика данных «sudo» в список служб, так как он стал необязательным. Однако вместо этого следует включить sssd-sudo.socket.

Когда программа SSSD настроена на использование IPA в качестве поставщика ID, включение поставщика данных sudo выполняется автоматически. База поиска sudo настроена на использование собственного дерева LDAP IPA (cn=sudo,$SUFFIX). Если в sssd.conf определена какая-либо другая база поиска, будет использоваться это значение. Дерево совместимости (ou=sudoers,$SUFFIX) больше не является необходимым для работы sudo IPA.

## Механизм кэширования правил SUDO
При разработке поддержки sudo в SSSD сложнее всего было сделать так, чтобы работа sudo c SSSD в качестве источника данных обеспечивала такие же скорость и взаимодействие с пользователем, что и sudo, при этом предоставляя настолько актуальный набор правил, насколько это возможно. Для этого в SSSD используются три вида обновлений: полное обновление, интеллектуальное обновление и обновление правил.

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

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

Обновление правил обеспечивает, что пользователю не будет предоставлено больше прав, чем определено. Это обновление выполняется при каждом запуске sudo пользователем. Обновление правил находит все правила, которые применяются к этому пользователю, проверяет срок их действия и повторно загружает их, если этот срок истёк. Если на сервере отсутствуют какие-либо из таких правил, SSSD выполнит общее полное обновление, так как могло быть удалено гораздо больше правил (применяемых к другим пользователям).

Если этот параметр включён, SSSD будет сохранять только правила, которые могут быть применены к этому компьютеру. Это те правила, которые содержат в атрибуте sudoHost одно из следующих значений:

•ключевое слово ALL

•подстановочный знак

•сетевая группа (в виде «+netgroup»)

•имя узла или полное доменное имя компьютера

•один из IP-адресов компьютера

•один из IP-адресов сети (в виде «address/mask»)

Предусмотрено много параметров, которыми можно воспользоваться для настройки поведения программы. Подробное описание доступно в разделах «ldap_sudo_*» sssd-ldap(5) и «sudo_*» sssd.conf(5).

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

1. Индексируйте атрибуты LDAP. Убедитесь, что выполняется индексирование следующих атрибутов LDAP: objectClass, cn, entryUSN и modifyTimestamp.

2. Задайте ldap_sudo_search_base. Укажите в качестве базы поиска контейнер, который содержит правила sudo, чтобы ограничить область поиска.

3. Задайте интервал полного и интеллектуального обновления. Если правила sudo меняются редко и не требуется быстро обновлять кэшированные правила на клиентах, можно увеличить значения ldap_sudo_full_refresh_interval и ldap_sudo_smart_refresh_interval. Также можно отключить интеллектуальное обновление: ldap_sudo_smart_refresh_interval = 0.

4. Если имеется большое количество клиентов, можно увеличить значение ldap_sudo_random_offset для лучшего распределения нагрузки на сервер.

## СМ. ТАКЖЕ
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

## AUTHORS
Восходящий источник («апстрим») SSSD — https://github.com/SSSD/sssd/