sss-certmap

title: sss-certmap(5)

text:
# sss-certmap(5)

## NAME
sss-certmap - Правила установления соответствия и сопоставления сертификатов SSSD

## ОПИСАНИЕ
На этой справочной странице приводится описание правил, которые могут использоваться SSSD и другими компонентами для установления соответствия сертификатов X.509 и их сопоставления с учётными записями.

Каждое правило содержит четыре компонента, “приоритет”, “правило установления соответствия”, “правило сопоставления” и “список доменов”. Все компоненты являются необязательными. Если отсутствует “приоритет”, будет добавлено правило с самым низким приоритетом. Стандартное “правило установления соответствия” устанавливает соответствие сертификатов с использованием ключа digitalSignature и расширенным использованием ключа clientAuth. Если “правило сопоставления” не указано, в атрибуте userCertificate будет выполняться поиск сертификатов как двоичных файлов в кодировке DER. Если не указаны домены, поиск будет выполняться только в локальном домене.

Чтобы разрешить расширения или совершенно другой стиль правила, “сопоставления” и “правила соответствия” могут содержать префикс, отделенный символом «:» от основной части правила. Префикс может содержать только ASCII-буквы верхнего регистра и цифры. Если префикс опущен, будет использоваться тип по умолчанию: «KRB5» для правил соответствия и «LDAP» для правил сопоставления.

Утилита 'sssctl' предоставляет команду 'cert-eval-rule', предназначенную для проверки, соответствует ли указанный сертификат правилам соответствия, и определяет, как будет выглядеть вывод правила сопоставления.

## КОМПОНЕНТЫ ПРАВИЛА

### ПРИОРИТЕТ
Правила обрабатываются в порядке приоритета. Ноль «0» означает наивысший приоритет. Чем больше число, тем выше приоритет. Отсутствие значения означает самый низкий приоритет. Обработка правил останавливается при обнаружении соответствующего условиям правила, и никакие другие правила уже не проверяются.

На внутреннем уровне приоритет обрабатывается как беззнаковое 32-битное целое. Использование значения приоритета, превышающего 4294967295, приведёт к ошибке.

Если несколько правил имеют одинаковый приоритет, но только одно соответствует связанным правилам установления соответствия, будет выбрано это правило. Если имеется несколько правил с одинаковым приоритетом, которые соответствуют, будет выбрано одно из них, но не будет определено, какое именно. Чтобы предотвратить такое неопределённое поведение, следует либо задать разный приоритет, либо сделать правила установления соответствия более чёткими (например, с помощью разных шаблонов <ISSUER>).

### ПРАВИЛО УСТАНОВЛЕНИЯ СООТВЕТСТВИЯ
Правило установления соответствия используется для выбора сертификата, к которому следует применить правило сопоставления. В нём используется система, похожую на ту, которая используется в параметре “pkinit_cert_match” MIT Kerberos. Правило состоит из ключевого слова, расположенного между «<» и «>», которое идентифицирует определённую часть сертификата, и шаблона, который должен быть найден для установления соответствия правила. Несколько пар «ключевое слово — шаблон» можно соединить с помощью логического оператора «&&» (и) или «||» (или).

Учитывая сходство с MIT Kerberos, префиксом для этого правила является «KRB5». Но «KRB5» также будет использоваться по умолчанию для “правил установления соответствия”, поэтому «<SUBJECT>.*,DC=MY,DC=DOMAIN» и «KRB5:<SUBJECT>.*,DC= MY,DC=DOMAIN» эквивалентны.

Доступные параметры:

<SUBJECT>регулярное_выражение

Это правило позволяет установить соответствие части или всего имени субъекта сертификата. Для установления соответствия используется синтаксис расширенных регулярных выражений POSIX. Подробное описание синтаксиса доступно на справочной странице regex(7). Для установления соответствия имени субъекта, которое хранится в сертификате в кодировке DER, ASN.1 преобразуется в строку в соответствии с RFC 4514. Это означает, что сначала идёт наиболее специфичный компонент имени. Обратите внимание, что в стандарте RFC 4514 перечислены не все возможные имени атрибутов. В него включены имена «CN», «L», «ST», «O», «OU», «C», «STREET», «DC» и «UID». Другие имена атрибутов могут отображаться по-разному на различных платформах и с помощью различных инструментов. Чтобы избежать путаницы, рекомендуется не использовать такие имена и не покрывать их соответствующим регулярным выражением.

Пример: <SUBJECT>.*,DC=MY,DC=DOMAIN

Обратите внимание, что символы «^.[$()|*+?{\» имеют специальное значение в регулярных выражениях, поэтому их необходимо экранировать с помощью символа «\», чтобы программа воспринимала их как обычные символы.

Пример: <SUBJECT>^CN=.* \(Admin\),DC=MY,DC=DOMAIN$

<ISSUER>регулярное_выражение

Это правило позволяет установить соответствие части или всего имени издателя сертификата. Этого параметра касаются те же комментарии, которые были указаны для <SUBJECT>. Пример: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$

<KU>использование_ключа

С помощью этого параметра можно указать, какие значения использования ключа должен иметь сертификат. В разделённом запятыми списке можно указать следующие значения:

•digitalSignature

•nonRepudiation

•keyEncipherment

•dataEncipherment

•keyAgreement

•keyCertSign

•cRLSign

•encipherOnly

•decipherOnly

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

Пример: <KU>digitalSignature,keyEncipherment

<EKU>расширенное_использование_ключа

С помощью этого параметра можно указать, какие значения расширенного использования ключа должен иметь сертификат. В разделённом запятыми списке можно указать следующие значения:

•serverAuth

•clientAuth

•codeSigning

•emailProtection

•timeStamping

•OCSPSigning

•KPClientAuth

•pkinit

•msScLogin

Расширенные использования ключа, которые не входят в представленный выше список, можно указать по их OID в десятичной записи.

Пример: <EKU>clientAuth,1.3.6.1.5.2.3.4

<SAN>регулярное_выражение

Для обеспечения совместимости с использованием MIT Kerberos этот параметр будет устанавливать соответствие участников Kerberos в SAN PKINIT или SAN AD NT Principal так, как это делает <SAN:Principal>. Пример: <SAN>.*@MY\.REALM

<SAN:Principal>регулярное_выражение

Установить соответствие участников Kerberos в SAN PKINIT или SAN AD NT Principal. Пример: <SAN:Principal>.*@MY\.REALM

<SAN:ntPrincipalName>регулярное_выражение

Установить соответствие участников Kerberos в SAN AD NT Principal. Пример: <SAN:ntPrincipalName>.*@MY.AD.REALM

<SAN:pkinit>регулярное_выражение

Установить соответствие участников Kerberos в SAN PKINIT. Пример: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM

<SAN:dotted-decimal-oid>регулярное_выражение

Взять значение компонента otherName SAN, указанное с помощью OID в десятичном формате, интерпретировать его как строку и попытаться установить его соответствие регулярному выражению. Пример: <SAN:1.2.3.4>test

<SAN:otherName>строка_base64

Выполнить установление двоичного соответствия blob-объекта в кодировке base64 всем компонентам otherName SAN. С помощью этого параметра возможно устанавливать соответствие пользовательским компонентам otherName в особых кодировках, которые не могут обрабатываться как строки. Пример: <SAN:otherName>MTIz

<SAN:rfc822Name>регулярное_выражение

Установить соответствие значения SAN rfc822Name. Пример: <SAN:rfc822Name>.*@email\.domain

<SAN:dNSName>регулярное_выражение

Установить соответствие значения SAN dNSName. Пример: <SAN:dNSName>.*\.my\.dns\.domain

<SAN:x400Address>строка_base64

Установить двоичное соответствие значения SAN x400Address. Пример: <SAN:x400Address>MTIz

<SAN:directoryName>регулярное_выражение

Установить соответствие значения SAN directoryName. Этого параметра касаются те же комментарии, которые были указаны для <ISSUER> и <SUBJECT>. Пример: <SAN:directoryName>.*,DC=com

<SAN:ediPartyName>строка_base64

Установить двоичное соответствие значения SAN ediPartyName. Пример: <SAN:ediPartyName>MTIz

<SAN:uniformResourceIdentifier>регулярное_выражение

Установить соответствие значения SAN uniformResourceIdentifier. Пример: <SAN:uniformResourceIdentifier>URN:.*

<SAN:iPAddress>регулярное_выражение

Установить соответствие значения SAN iPAddress. Пример: <SAN:iPAddress>192\.168\..*

<SAN:registeredID>регулярное_выражение

Установить соответствие значения SAN registeredID в виде десятичной строки. Пример: <SAN:registeredID>1\.2\.3\..*

### ПРАВИЛО СОПОСТАВЛЕНИЯ
Правило сопоставления используется для связывания сертификата с одной или несколькими учётными записями. После этого для прохождения проверки подлинности в качестве одной из этих учётных записей будет можно использовать смарт-карту с сертификатом и соответствующим закрытым ключом.

В настоящее время SSSD поддерживает поиск данных пользователей в основном только в LDAP (исключение — поставщик данных прокси, что несущественно в данном контексте). Поэтому правило сопоставления основано на синтаксисе фильтра поиска LDAP с шаблонами для добавления содержимого сертификата в фильтр. Ожидается, что фильтр будет содержать только определённые данные, необходимые для сопоставления, и что вызывающая сторона внедрит их в другой фильтр для выполнения фактического поиска. Поэтому строка фильтра должна, соответственно, начинаться символом «(» и заканчиваться символом «)».

В целом, рекомендуется использовать атрибуты из сертификата и добавлять их к специальным атрибутам объекта пользователя LDAP. Например, можно использовать атрибут «altSecurityIdentities» в AD или атрибут «ipaCertMapData» для IPA.

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

Типом “правила сопоставления” по умолчанию является «LDAP», который можно добавить в качестве префикса к правилу, например. 'LDAP:(userCertificate;binary={cert!bin})'. Расширение «LDAPU1» предоставляет дополнительные шаблоны для увеличения гибкости. Чтобы разрешить устаревшим версиям этой библиотеки игнорировать расширения, при использовании новых шаблонов в “правиле сопоставления” должен быть использован префикс «LDAPU1», иначе работа устаревшей версии этой библиотеки будет завершена с сообщением об ошибке при обработке входных данных. Новые шаблоны описаны в разделе the section called “Расширение LDAPU1”.

Шаблоны для добавления данных сертификата в фильтр поиска основаны на строках форматирования в стиле Python. Они состоят из ключевого слова в фигурных скобках с необязательным указателем подкомпонента, который отделён знаком «.», или необязательным параметром преобразования/форматирования, который отделён знаком «!». Допустимые значения:

{issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

Этот шаблон добавит полное DN издателя, преобразованное в строку в соответствии с RFC 4514. Для упорядочения X.500 (самое специфичное RDN в конце) следует использовать параметр с префиксом «_x500». Параметры преобразования, которые начинаются с «ad_», используют имена атрибутов, используемые AD (например, «S» вместо «ST»).

Параметры преобразования, которые начинаются с «nss_», используют имена атрибутов, используемые NSS.

Стандартным вариантом преобразования является «nss», то есть имена атрибутов согласно NSS и упорядочение LDAP/RFC 4514.

Пример: (ipacertmapdata=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})

{subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

Этот шаблон добавит полное DN субъекта, преобразованное в строку в соответствии с RFC 4514. Для упорядочения X.500 (самое специфичное RDN в конце) следует использовать параметр с префиксом «_x500». Параметры преобразования, которые начинаются с «ad_», используют имена атрибутов, используемые AD (например, «S» вместо «ST»).

Параметры преобразования, которые начинаются с «nss_», используют имена атрибутов, используемые NSS.

Стандартным вариантом преобразования является «nss», то есть имена атрибутов согласно NSS и упорядочение LDAP/RFC 4514.

Пример: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})

{cert[!(bin|base64)]}

Этот шаблон добавит в фильтр поиска весь сертификат в кодировке DER как строку. В зависимости от значения параметра преобразования двоичный сертификат будет преобразован либо в экранированную шестнадцатеричную последовательность «\xx», либо в код base64. Стандартным вариантом является экранированная шестнадцатеричная последовательность. Она может использоваться, например, с атрибутом LDAP «userCertificate;binary». Пример: (userCertificate;binary={cert!bin})

{subject_principal[.short_name]}

Этот шаблон добавит участника Kerberos, взятого либо из SAN, используемого pkinit, либо из SAN, используемого AD. Компонент «short_name» представляет первую часть записи участника, до знака «@». Пример: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))

{subject_pkinit_principal[.short_name]}

Этот шаблон добавит участника Kerberos, который указан в SAN, используемом pkinit. Компонент «short_name» представляет первую часть записи участника, до знака «@». Пример: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name}))

{subject_nt_principal[.short_name]}

Этот шаблон добавит участника Kerberos, который указан в SAN, используемом AD. Компонент «short_name» представляет первую часть записи участника, до знака «@». Пример: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name}))

{subject_rfc822_name[.short_name]}

Этот шаблон добавит строку, которая хранится в компоненте rfc822Name SAN (обычно это адрес электронной почты). Компонент «short_name» представляет первую часть записи адреса, до знака «@». Пример: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name}))

{subject_dns_name[.short_name]}

Этот шаблон добавит строку, которая хранится в компоненте dNSName SAN (обычно это полное имя узла) Компонент «short_name» представляет первую часть записи имени, до первого знака «.». Пример: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name}))

{subject_uri}

Этот шаблон добавит строку, которая хранится в компоненте uniformResourceIdentifier SAN. Пример: (uri={subject_uri})

{subject_ip_address}

Этот шаблон добавит строку, которая хранится в компоненте iPAddress SAN. Пример: (ip={subject_ip_address})

{subject_x400_address}

Этот шаблон добавит значение, которое хранится в компоненте x400Address SAN как экранированная шестнадцатеричная последовательность. Пример: (attr:binary={subject_x400_address})

{subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

Этот шаблон добавит строку DN значения, которое хранится в компоненте directoryName SAN. Пример: (orig_dn={subject_directory_name})

{subject_ediparty_name}

Этот шаблон добавит значение, которое хранится в компоненте ediPartyName SAN как экранированная шестнадцатеричная последовательность. Пример: (attr:binary={subject_ediparty_name})

{subject_registered_id}

Этот шаблон добавит OID, который хранится в компоненте registeredID SAN как десятичная строка. Пример: (oid={subject_registered_id})

Расширение LDAPU1

The following templates are available when using the 'LDAPU1' extension:

{serial_number[!(dec|hex[_ucr])]}

Этот шаблон добавит серийный номер сертификата. По умолчанию он будет напечатан как шестнадцатеричное число буквами нижнего регистра. Если используется параметр форматирования «!dec», число будет выведено в виде десятичной строки. Шестнадцатеричный вывод может быть показан буквами в верхнем регистре («!hex_u»), с двоеточием, разделяющим шестнадцатеричные байты («!hex_c»), или с шестнадцатеричными байтами в обратном порядке («!hex_r»). Буквы постфикса можно комбинировать, например, «!hex_uc» приведет к выводу шестнадцатеричной строки, разделенной двоеточием, с буквами в верхнем регистре.

Пример: LDAPU1:(serial={серийный_номер})

{subject_key_id[!hex[_ucr]]}

Этот шаблон добавит идентификатор ключа назначения сертификата. По умолчанию он будет напечатан как шестнадцатеричное число буквами нижнего регистра. Шестнадцатеричный вывод может быть показан буквами в верхнем регистре («!hex_u»), с двоеточием, разделяющим шестнадцатеричные байты («!hex_c»), или с шестнадцатеричными байтами в обратном порядке («!hex_r»). Буквы постфикса можно комбинировать, например, «!hex_uc» приведет к выводу шестнадцатеричной строки, разделенной двоеточием, с буквами в верхнем регистре.

Пример: LDAPU1:(ski={subject_key_id})

{cert[!DIGEST[_ucr]]}

Этот шаблон добавит шестнадцатеричную контрольную сумму или хэш к сертификату. Запись DIGEST должна быть заменена названием функции контрольной суммы или хэша, поддержка которых предусмотрена в OpenSSL, например. «sha512». Шестнадцатеричный вывод может быть показан буквами в верхнем регистре («!sha512_u»), с двоеточием, разделяющим шестнадцатеричные байты («!sha512_c»), или с шестнадцатеричными байтами в обратном порядке («!sha512_r»). Буквы постфикса можно комбинировать, например, «!sha512_uc» приведет к выводу шестнадцатеричной строки, разделенной двоеточием, с буквами в верхнем регистре.

Пример: LDAPU1:(dgst={cert!sha256})

{subject_dn_component[(.attr_name|[number]]}

Этот шаблон добавит значение атрибуту компонента DN субъекта, по умолчанию значением является самый специфический компонент. A different component can be selected by either attribute name, e.g. {subject_dn_component.uid} or by position, e.g. {subject_dn_component.[2]} where positive numbers start counting from the most specific component and negative numbers start counting from the least specific component. Attribute name and the position can be combined as e.g. {subject_dn_component.uid[2]} which means that the name of the second component must be 'uid'.

Пример: LDAPU1:(uid={subject_dn_component.uid})

{issuer_dn_component[(.attr_name|[number]]}

Этот шаблон добавит значение атрибуту компонента DN издателя, по умолчанию значением является самый специфический компонент. См. раздел «subject_dn_component» для получения более подробной информации о названиях атрибутов и спецификаторов позиции.

Пример: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]})

{sid[.rid]}

Этот шаблон добавит SID, если доступно соответствующее расширение, представленное Microsoft с OID 1.3.6.1.4.1.311.25.2. С помощью селектора «.rid» будет добавлен только последний компонент, то есть RID. Пример: LDAPU1:(objectsid={sid})

### СПИСОК ДОМЕНОВ
Когда список доменов не пуст, поиск пользователей, сопоставленных указанному сертификату, будет выполняться не только в локальном домене, но также и в перечисленных в списке доменах, если они известны SSSD. Домены, которые неизвестны SSSD, будут игнорироваться.

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


manpath

package: man-db

title: manpath(5)

summary: формат файла /etc/man_db.conf

text:
# manpath(5)

## НАЗВАНИЕ
manpath - формат файла /etc/man_db.conf

## ОПИСАНИЕ
Файл настройки manpath используется утилитами справочных страниц для доступа к пользовательским manpath во время работы; в нём определено какие иерархии справочных страниц (manpath) считать системными иерархиями, а также для них назначены каталоги хранения cat файлов.

Если установлена переменная окружения $MANPATH, то информация из /etc/man_db.conf использоваться не будет.

## ПУТЬ ПОИСКА
ПО умолчанию, man-db проверяет $PATH пользователя. Для каждого найденного там элемента_пути, она добавляет элемент_manpath в путь поиска.

Если в файле настроек нет строки MANPATH_MAP для данного элемента_пути, то в путь поиска добавляются элемент_пути/../man, элемент_пути/man, элемент_пути/../share/man и элемент_пути/share/man, если они существуют в виде каталогов.

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

И, наконец, если указан параметр --systems или задана переменная окружения $SYSTEM, то они должны состоять из последовательности имён операционных систем, разделённых запятыми или двоеточиями. Их значения служат шаблонами, расширяющими путь поиска ещё больше, предоставляя доступ к справочным страницам других операционных систем: для каждого имени системы, man-db ищет подкаталог с таким именем в каждом элементе пути поиска, и если он существует, то добавляет его в окончательный путь поиска. Системное имя man вставляется в обычный путь поиска без подкаталогов. Например. если имеется путь поиска /usr/share/man:/usr/local/man, и $SYSTEM равна newOS:man, то окончательный путь поиска будет /usr/share/man/newOS:/usr/share/man:/usr/local/man/newOS:/usr/local/man.

Переменная окружения $MANPATH заменяет в man-db пути поиска страниц по умолчанию. Большинству пользователей не требуется её задавать. Её синтаксис похож на переменную окружения $PATH: значение состоит из последовательности имён каталогов, разделённых двоеточиями. Оно заменяет путь поиска по умолчанию, описанное выше.

Если значение $MANPATH начинается с двоеточия, то оно добавляется в конец пути поиска по умолчанию. Если значение $MANPATH оканчивается двоеточием, то оно добавляется в начало пути поиска по умолчанию. Если значение $MANPATH содержит два двоеточия подряд (::), то путь поиска по умолчанию вставляется в середину значения между этими двоеточиями.

## ФОРМАТ
В данный момент распознаются следующие типы полей:

\# комментарий

Пустые или начинающиеся с # строки считаются комментариями и игнорируются.

MANDATORY_MANPATH manpath_элемент

Строки в этом формате содержат manpath, которые каждый раз генерируются автоматически для включения в $MANPATH. Обычно, сюда включается /usr/man.

MANPATH_MAP элемент_пути manpath_элемент

Строки в этом формате содержат отображение $PATH в $MANPATH. Для каждого элемента_пути, найденного в пользовательском $PATH, в $MANPATH будет добавляться manpath_элемент.

MANDB_MAP manpath_элемент [ catpath_элемент ]

Строки в этом формате определяют, какие manpath должны считаться системными manpath, а также можно задать для каких из них нужно хранить cat файлы. Этот тип поля особенно важен, если man является setuid программой, так как (когда задаются в системном файле настройки /etc/man_db.conf, а не в персональном файле настройки пользователя .manpath) им определяется, к каким иерархиям справочных страниц имеет доступ setuid пользователь, а какие вызываются из-под обычного пользователя. Системные иерархии справочных страниц обычно хранятся в подкаталогах /usr, например, /usr/man, /usr/local/man и /usr/X11R6/man.

Если cat страницы из определённого manpath_элемента не нужно хранить, или они будут храниться в обычном месте, то catpath_элемент можно не указывать.

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

К сожалению, требуется указать все пути системных справочных страниц, включая пути альтернативных операционных систем, такие как /usr/man/sun и все пути локалей NLS, например /usr/man/de_DE.88591.

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

DEFINE ключ значение

Строки в этом формате определяют различные переменные настройки; в файле настройки по умолчанию описаны переменные, которые используются утилитами пейджера справочных страниц. Они могут содержать пути по умолчанию к различным программам (например, grep и tbl) и параметры по умолчанию для этих программ.

SECTION раздел ...

Строки данного формата определяют порядок поиска в справочных разделах. Если в файле настройки директивы SECTION не указаны, то по умолчанию используется:

```
SECTION 1 n l 8 3 0 2 3type 5 4 9 6 7
```

Если указано несколько директив SECTION, то их значения объединяются в список.

Если какого-то расширения не окажется в этом списке (например, 1mh), то страница будет показана вместе с оставшимся разделом, которому принадлежит. Смысл этого в том, что нужно указывать только расширения, для которых вы бы хотели жёстко задать определённый порядок. Разделы с расширениями, как правило, указываются рядом с их основным разделом (например, "1 1mh 8 ...").

В качестве альтернативного имени этой директивы может использоваться SECTIONS.

MINCATWIDTH ширина

Если ширина терминала меньше чем ширина, то cat страницы создаваться (если их нет) или отображаться не будут. Значение по умолчанию равно 80.

MAXCATWIDTH ширина

Если ширина терминала больше чем ширина, то cat страницы создаваться (если их нет) или отображаться не будут. Значение по умолчанию равно 80.

CATWIDTH ширина

Если значение ширина не равно 0, то cat страницы будут всегда форматироваться для терминала данной ширины, независимо от ширины терминала, который используется на самом деле. Это значение заменяет MINCATWIDTH и MAXCATWIDTH.

NOCACHE

Этот параметр запрещает man(1) автоматически создавать cat страницы.

## ОШИБКИ
Если точно не следовать правилам, описанным ранее, то утилиты пейджера справочных страниц не будут работать как ожидалось. Правила чрезмерно запутаны.

https://gitlab.com/man-db/man-db/-/issues

https://savannah.nongnu.org/bugs/?group=man-db

branch: sisyphus


acct

package: man-pages-ru

title: acct(5)

summary: файл учёта процессов

text:
# acct(5)

## ИМЯ
acct - файл учёта процессов

## ОБЗОР
\#include <sys/acct.h>

## ОПИСАНИЕ
Если ядро собрано с включённым параметром учёта процессов (CONFIG_BSD_PROCESS_ACCT), то системный вызов acct(2) запустит учёт процесса:

acct("/var/log/pacct");

При включённом учёте процессов, ядро делает запись в файл учёта по каждому процессу системы по его завершении. Эта запись содержит информацию о завершённом процессе и определена в <sys/acct.h> следующим образом:

```
#define ACCT_COMM 16
typedef u_int16_t comp_t;
struct acct {

    char ac_flag;           /* флаги учёта */

    u_int16_t ac_uid;       /* ID пользователя */

    u_int16_t ac_gid;       /* ID группы */

    u_int16_t ac_tty;       /* управляющий терминал */

    u_int32_t ac_btime;     /* время создания процесса

                               (в секундах с начала эпохи) */

    comp_t    ac_utime;     /* время работы ЦП в пользовательском режиме */

    comp_t    ac_stime;     /* время работы ЦП в системном режиме */

    comp_t    ac_etime;     /* прошедшее время */

    comp_t    ac_mem;       /* среднее количество использованной памяти (КБ) */

    comp_t    ac_io;        /* передано символов (не используется) */

    comp_t    ac_rw;        /* прочитано или записано блоков (не используется) */

    comp_t    ac_minflt;    /* промахи для вспомогательных страниц */

    comp_t    ac_majflt;    /* промахи для главных страниц */

    comp_t    ac_swaps;     /* количество подкачек (не используется) */

    u_int32_t ac_exitcode;  /* код завершения процесса

                               (см. wait(2)) */

    char      ac_comm[ACCT_COMM+1];

                            /* имя команды (basename от последней

                               исполнявшейся команды; завершается null) */

    char      ac_pad[X];    /* байты заполнения */
};
enum {                      /* биты для поля ac_flag */

    AFORK = 0x01,           /* был выполнен fork, но не exec */

    ASU   = 0x02,           /* использовались права суперпользователя */

    ACORE = 0x08,           /* создан файл core */

    AXSIG = 0x10            /* завершён по сигналу */
};
```

Тип данных comp_t — это число с плавающей точкой, состоящее из 3-битной экспоненты по основанию 8 и 13-битной мантиссы. Переменная c этого типа может быть преобразована к целому (long) так:

```
    v = (c & 0x1fff) << (((c >> 13) & 0x7) * 3);
```

Поля ac_utime, ac_stime и ac_etime хранят время в "тактах часов"; для преобразования в секунды нужно поделить значение на sysconf(_SC_CLK_TCK).

### Формат файла учёта версии 3
Начиная с ядра версии 2.6.8, можно создавать файл учёта альтернативной версии, если задать параметр CONFIG_BSD_PROCESS_ACCT_V3 при сборке ядра. Если этот параметр установлен, то записи, сохранённые в файле учёта, будут содержать дополнительные поля, а ширина полей c_uid и ac_gid будет расширена с 16 до 32 бит (для соответствия с увеличенным размером UID и GID в Linux 2.4 и новее). Записи определены следующим образом:

```
struct acct_v3 {

    char      ac_flag;      /* флаги */

    char      ac_version;   /* всегда равно ACCT_VERSION (3) */

    u_int16_t ac_tty;       /* управляющий терминал */

    u_int32_t ac_exitcode;  /* код завершения процесса

    u_int32_t ac_uid;       /* реальный ID пользователя */

    u_int32_t ac_gid;       /* реальный ID группы */

    u_int32_t ac_pid;       /* ID процесса */

    u_int32_t ac_ppid;      /* ID родительского процесса */

    u_int32_t ac_btime;     /* время создания процесса

    float     ac_etime;     /* прошедшее время */

    comp_t    ac_utime;     /* время работы ЦП в пользовательском режиме */

    comp_t    ac_stime;     /* время работы ЦП в системном режиме */

    comp_t    ac_mem;       /* среднее количество использованной памяти (КБ) */

    comp_t    ac_io;        /* передано символов (не используется) */

    comp_t    ac_rw;        /* прочитано или записано блоков

                            (не используется) */

    comp_t    ac_minflt;    /* промахи для вспомогательных страниц */

    comp_t    ac_majflt;    /* промахи для главных страниц */

    comp_t    ac_swaps;     /* количество подкачек (не используется) */

    char      ac_comm[ACCT_COMM]; /* имя команды */
};
```

## ВЕРСИИ
Структура acct_v3 определена в glibc начиная с версии 2.6.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Учёт процессов возник в BSD. Хотя он есть в большинстве систем, он не стандартизован, и параметры разнятся между системами.

## ЗАМЕЧАНИЯ
Записи в файле учёта упорядочены по времени завершения процессов.

В ядрах до версии 2.6.9 включительно, с помощью библиотеки нитей NPTL для каждой нити сохранялась своя запись учёта; начиная с Linux 2.6.10 отдельная запись сохраняется для всего процесса при завершении работы его последней нити.

В файле /proc/sys/kernel/acct, описанном в proc(5), определены настройки, которые управляют поведением учёта процессов при нехватке места на диске.

## СМОТРИТЕ ТАКЖЕ
lastcomm(1), acct(2), accton(8), sa(8)


charmap

title: charmap(5)

summary: файл описания набора символов

text:
# charmap(5)

## ИМЯ
charmap - файл описания набора символов

## ОПИСАНИЕ
Описание набора символов (charmap) определяет набор из всех доступных символов, а также их кодировки. Эти описания можно использовать в localedef(1) для создания вариантов локали с различными наборами символов.

### СИНТАКСИС
Файл с набором символов начинается с заголовка, который может содержать следующие ключевые слова:

<code_set_name>

за которым следует имя набора символов.

<comment_char>

за которым указывается символ, использующийся в оставшихся строках файла как символ комментария. По умолчанию это символ решётки (#).

<escape_char>

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

<mb_cur_max>

за которым следует максимальное количество байтов на символ. По умолчанию это число равно 1.

<mb_cur_min>

за которым следует минимальное количество байтов на символ. Данное значение должно быть меньше или равно <mb_cur_max>. Если оно не задано, то по умолчанию принимается значение <mb_cur_max>.

Раздел определения набора символов начинается с ключевого слова CHARMAP в первом столбце.

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

<символ> последовательность-байт комментарий

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

<символ>..<символ> последовательность-байт комментарий

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

Раздел определения набора символов заканчивается строкой END CHARMAP.

За разделом определения набора символов может следовать раздел ширины символов.

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

Раздел ширины отдельных символов начинается с ключевого слова WIDTH в первом столбце.

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

<символ> ширина

В таком виде задаётся ширина только одного символа.

<символ>…<символ> ширина

В таком виде задаётся ширина всех символов в диапазоне.

Раздел определения ширины заканчивается строкой END WIDTH.

## ФАЙЛЫ
/usr/share/i18n/charmaps

Обычный путь по умолчанию для файлов карт символов.

## СООТВЕТСТВИЕ СТАНДАРТАМ
POSIX.2.

## ПРИМЕР
Знак евро определяется в наборе символов UTF-8 следующим образом:

```
<U20AC>     /xe2/x82/xac EURO SIGN
```

## СМОТРИТЕ ТАКЖЕ
iconv(1), locale(1), localedef(1), locale(5), charsets(7)


core

title: core(5)

summary: файла дампа памяти процесса

text:
# core(5)

## ИМЯ
core - файла дампа памяти процесса

## ОПИСАНИЕ
Для определённых сигналов действием по умолчанию является завершение процесса и создание дампа памяти процесса — дискового файла, содержащего образ памяти процесса на момент завершения. Этот образ может быть использован в отладчике (например, gdb(1)) для исследования состояния программы на момент её завершения. Список сигналов, которые приводят к созданию дампа памяти процесса, можно найти в signal(7).

Процесс может установить свой программный предел ресурса RLIMIT_CORE в максимальное значение по размеру файла дампа, который будет создан, если процесс получит сигнал "дампа памяти"; подробней смотрите в getrlimit(2).

Есть несколько обстоятельств, при которых файл дампа памяти не создаётся:

- У процесса нет прав на запись файла дампа (по умолчанию файл дампа называется core или core.pid, где pid — ID процесса из которого делается дамп, и создаётся в текущем рабочем каталоге. Подробней об именовании смотрите далее). Запись файла дампа завершается ошибкой, если каталог, в котором он создаётся, недоступен для записи, или если файл с таким же именем уже существует и недоступен для записи или это необычный файл (например, это каталог или символьная ссылка).

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

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

- Каталог, в котором должен быть создан файл дампа, не существует.

- Пределы ресурсов RLIMIT_CORE (размер файла дампа) или RLIMIT_FSIZE (размер файла) для процесса установлены в ноль; смотрите getrlimit(2) и документацию на команду оболочки ulimit (limit в csh(1)).

- Исполняемый процессом файл недоступен на чтение.

- Процесс выполняет программу с установленными битом set-user-ID (set-group-ID), который принадлежит пользователю (группе) не совпадающей с ID реального пользователя (группы) процесса или процесс выполняется программу, имеющую файловые мандаты (смотрите capabilities(7)). Однако посмотрите описание операции prctl(2) PR_SET_DUMPABLE, и описание файла /proc/sys/fs/suid_dumpable в proc(5).

- Файл /proc/sys/kernel/core_pattern пуст и /proc/sys/kernel/core_uses_pid содержит 0 (эти файлы описаны ниже). Заметим, что если /proc/sys/kernel/core_pattern пуст и /proc/sys/kernel/core_uses_pid содержит 1, то файлы дампа будет иметь имена в виде .pid, а такие файлы не показываются при использовании ls(1) с параметром -a.

- (начиная с Linux 3.7) Ядро настроено без параметра CONFIG_COREDUMP.

Также, дамп память может не содержать часть адресного пространства процесса, если в madvise(2) указан флаг MADV_DONTDUMP.

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

### Именование файлов дампов памяти
По умолчанию, файлу с дампом памяти присваивается имя core, но с помощью файла /proc/sys/kernel/core_pattern (начиная с Linux 2.6 и 2.4.21) можно задать шаблон, который будет использован для именования файлов дампов памяти. Шаблон может содержать описатели %, которые заменяются на следующие значения при создании файла дампа:

%%

одиночный символ %

%c

программный предел размера файла дампа рухнувшего процесса (начиная с Linux 2.6.24)

%d

режим дампа — тоже, как значение возвращаемое prctl(2) с PR_GET_DUMPABLE (начиная с Linux 3.7)

%e

имя исполняемого файла (без пути)

%E

путь к исполняемому файлу, в котором символы косой черты ('/') заменена на восклицательные знаки ('!') (начиная с Linux 3.0).

%g

(число) реальный GID процесса, с которого делается дамп

%h

имя узла (как nodename, возвращаемое uname(2))

%i

TID нити, из-за которой возник дамп, по отношению к пространству имён PID, в котором располагается нить (начиная с Linux 3.18)

%I

TID нити, из-за которой возник дамп, по отношению к начальному пространству имён PID (начиная с Linux 3.18)

%p

PID процесса, с которого делается дамп, так как он видится в пространстве имён PID, котором расположен процесс

%P

initial PID процесса, с которого делается дамп, так как он видится в первоначальном пространстве имён PID, котором расположен процесс (начиная с Linux 3.12)

%s

номер сигнала, вызвавшего создание дампа

%t

время дампа, выражается в секундах с начала эпохи, 1970-01-01 00:00:00 +0000 (UTC)

%u

(число) реальный UID процесса, с которого делается дамп

Одиночный в конце шаблона отбрасывается от имени файла дампа вместе с символом после %, отличным от перечисленных ранее. Все остальные символы в шаблоне вставляются в имя файла дампа как есть. Шаблон может содержать символы '/', которые интерпретируются как разделители для имён каталогов. Максимальный размер получаемого имени файла дампа равен 128 байтам (64 байта для ядер до версии 2.6.19). Значение по умолчанию в этом файле равно "core". Для обратной совместимости, если /proc/sys/kernel/core_pattern не содержит %p и значение в /proc/sys/kernel/core_uses_pid (смотрите далее) не равно нулю, то к имени файла дампа будет добавлен .PID.

Пути рассматриваются согласно активным настройкам для падающего процесса. Имеется в виду пространство имён монтирования падающего процесса (смотрите mount_namespaces(7)), его текущий рабочий каталог (находимый с помощью getcwd(2)) и его корневой каталог (смотрите chroot(2)).

Начиная с версии 2.4, Linux также предоставляет более примитивный метод управления именем файла дампа памяти. Если файл /proc/sys/kernel/core_uses_pid содержит значение 0, то файл дампа памяти просто называется core. Если в этом файле содержится ненулевое значение, то к имени файла дампа добавится ID процесса (в виде core.PID).

Начиная с Linux 3.6, если значение в /proc/sys/fs/suid_dumpable равно 2 («suidsafe»), то шаблон должен быть или абсолютным путём (начинаться с символа '/'), или каналом, как описано далее.

### Передача дампов памяти в программу через канал
Начиная с версии 2.6.19, Linux поддерживает альтернативный синтаксис файла /proc/sys/kernel/core_pattern. Если первым символом в этом файле будет символ канала (|), то оставшаяся строка воспринимается как командная строка пользовательской программы (или сценария), которую нужно запустить.

Начиная с ядра 5.3.0 шаблон канала разделяется пробелами на аргументы до до раскрытия параметров шаблона. В старых ядрах параметры шаблона расширялись перед разделением пробелами списка аргументов. Это означает, что в старых ядрах имена исполняемых файлов добавляемые параметрами шаблона %e и %E, могли разделиться на несколько аргументов. Из-за этого обработчику дампа ядра (core dump handler) требовалось помещать имена исполняемых файлов в последний аргумент и проверять, что склеены все части имён исполняемых файлов, в которых есть пробелы. Имена исполняемых файлов с несколькими пробелами неправильно отображаются в старых ядрах, из-за чего обработчику дампа памяти требуется использовать механизмы поиска имени исполняемого файла.

Вместо записи файла на диск дамп памяти передаётся в стандартный ввод программы. Отметим следующие моменты:

- Программа должна быть задана абсолютным именем файла (или путём относительно корневого каталога, /), и имя должна сразу следовать за символом «|».

- В аргументах командной строки могут быть описатели %, перечисленные ранее. Например, чтобы передать PID процесса, для которого делается дамп, укажите в аргументе %p.

- Создаваемый процесс для запуска программы будет выполняться с правами группы и пользователя root.

- При выполнении с правами root не делается никаких исключений по обходу безопасности. А именно, LSM (например, SELinux) работает как обычно и может не дать обработчику доступ к информации упавшего процесса через /proc/[pid].

- Путь к программе рассматривается с учётом начального пространства имён монтирования, так как она всегда выполняется в нём. На это не влияют настройки (например, корневой каталог, пространство имён монтирования, текущий рабочий каталог) падающего процесса.

- Процесс выполняется в начальных пространствах имён (PID, монтирования, пользовательском и т. д.), а не в пространствах имён падающего процесса. Он может использовать описатели, например %P, для нахождения правильного каталога /proc/[pid] и, если нужно, протестировать/войти в пространства имён падающего процесса.

- Процесс запускается с корневым каталогом, равным своему текущему рабочему каталогу. Если нужно, то возможно изменить его на рабочий каталог выполняющего дамп процесса воспользовавшись значением описателя %P для изменения расположения выполняющего дамп процесса через /proc/[pid]/cwd.

- Программе можно передать аргументы командной строки (начиная с Linux 2.6.24), отделяя их пробелами (максимальный размер строки 128 байт).

- Ограничение RLIMIT_CORE не применяется к файлам дампа, которые передаются по каналу в программу через этот механизм.

### /proc/sys/kernel/core_pipe_limit
При отправке дампов памяти через канал в программу пользовательского пространства может быть полезным для собирающей программы получать данные о падающем процессе из каталога процесса /proc/[pid]. Для безопасного выполнения ядро должно дождаться завершения собирающей программы, и не удалять файлы падающего процесса /proc/[pid]. Это, в свою очередь, создаёт возможность того, что неправильно работающая собирающая программа может заблокировать очистку упавшего процесса просто никогда не завершаясь.

Начиная с Linux 2.6.32, для защиты от этого можно использовать файл /proc/sys/kernel/core_pipe_limit. Значением файла задаётся количество одновременно падающих процессов, которые можно передавать через канал программе из пространства пользователя параллельно. Если это значение превышено, то для выходящих за это ограничение падающих процессов ядро пишет сообщение в лог, а дампы памяти не передаёт.

Значение файла 0 является специальным. Оно означает, что параллельно можно пересылать бесконечное количество процессов, но ожидание при это не происходит (т. е., собирающей программе не гарантируется доступ к /proc/<crashing-PID>). Значение по умолчанию для файла равно 0.

### Управление отображениями, записываемыми в дамп памяти
Начиная с версии 2.6.23, в Linux появился файл /proc/[pid]/coredump_filter, который определяет какие сегменты памяти записываются в файл дампа памяти при отклике на событие создания дампа памяти процесса с соответствующим ID процесса.

Значение в файле является битовой маской типов отображений памяти (см. mmap(2)). Если бит в маске установлен, то выполняется дамп отображения памяти соответствующего типа; иначе дамп не выполняется. Биты в этом файле имеют следующее значение:

бит 0

Выполнять дамп анонимных частных отображений.

бит 1

Выполнять дамп анонимных общих отображений.

бит 2

Выполнять дамп частных отображений из виртуальной памяти (file-backed).

бит 3

Выполнять дамп общих отображений из виртуальной памяти (file-backed).

бит 4 (начиная с Linux 2.6.24)

Выполнять дамп заголовков ELF.

бит 5 (начиная с Linux 2.6.28)

Выполнять дамп частных огромных страниц.

бит 6 (начиная с Linux 2.6.28)

Выполнять дамп общих огромных страниц.

бит 7 (начиная с Linux 4.4)

Выполнять дамп частных страниц DAX.

бит 8 (начиная с Linux 4.4)

Выполнять дамп общих страниц DAX.

По умолчанию, установлены следующие биты: 0, 1, 4 (если включён параметр настройки ядра CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS) и 5. Данное значение может быть изменено при запуске системы через параметр загрузки coredump_filter.

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

Для страниц ввода-вывода, отображённых в память, таких как фрейм-буфер, дамп никогда не выполняется, а виртуальные страницы DSO (vdso(7)) попадают в дамп всегда, независимо от значения coredump_filter.

Дочерний процесс, созданный fork(2), наследует значение coredump_filter родителя; значение coredump_filter сохраняется и при execve(2).

Полезно указывать значение coredump_filter в родительской оболочке до запуска программы, например:

```
$ echo 0x7 > /proc/self/coredump_filter
$ ./какая-то_программа
```

Этот файл есть в системе только, если ядро было собрано с параметром настройки CONFIG_ELF_CORE.

### Файлы дампа и systemd
В системах с systemd(1) в качестве init файлы дампа могут помещаться в каталог, определяемый systemd(1). Для этого systemd(1) использует свойство core_pattern, которое позволяет передавать дампы программе по каналу. Это происходит, если файлы дампа передаются по каналу в программу systemd-coredump(8):

```
$ cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e
```

В этом случае файлы дампа будут помещаться согласно настройкам systemd-coredump(8), обычно в виде сжатых lz4(1) файлов в каталог /var/lib/systemd/coredump/. Список файлов дампа, записанных systemd-coredump(8), можно получить с помощью coredumpctl(1):

```
$ coredumpctl list | tail -5
Wed 2017-10-11 22:25:30 CEST  2748 1000 1000 3 present  /usr/bin/sleep
Thu 2017-10-12 06:29:10 CEST  2716 1000 1000 3 present  /usr/bin/sleep
Thu 2017-10-12 06:30:50 CEST  2767 1000 1000 3 present  /usr/bin/sleep
Thu 2017-10-12 06:37:40 CEST  2918 1000 1000 3 present  /usr/bin/cat
Thu 2017-10-12 08:13:07 CEST  2955 1000 1000 3 present  /usr/bin/cat
```

Информация, показываемая для каждого дампа включает дату и время дампа, PID, UID и GID процесса дампа, номер сигнала, вызвавшего дамп, и путь к исполняемому файлу, который был запущен процессом дампа. Различные параметры coredumpctl(1) позволяют выбрать файл coredump, который нужно записать из расположения systemd(1), в заданный файл. Например, чтобы извлечь дамп для PID 2955, показанного выше, в файл с именем core в текущий каталог, сделайте следующее:

```
$ coredumpctl dump 2955 -o core
```

Подробную информацию смотрите в справочной странице coredumpctl(1).

Для отключения в systemd(1) механизма архивирования дампом и восстановления чего-то более обычного поведению Linux, измените работу systemd(1) следующим образом:

```
# echo "kernel.core_pattern=core.%p" > /etc/sysctl.d/50-coredump.conf
# /lib/systemd/systemd-sysctl
```

## ЗАМЕЧАНИЯ
Команду gdb(1) gcore можно использовать для получения дампа памяти работающего процесса.

В версии Linux до 26.27 включительно, если для многонитевого процесса (или, точнее, процесса, который делит свою памяти с другим процессом, созданным с флагом CLONE_VM через clone(2)) выполняется дамп памяти, то ID процесса всегда добавляется к имени файла дампа, если ID процесса уже не включён в это имя с помощью %p в /proc/sys/kernel/core_pattern (это, главным образом, полезно когда применяется устаревшая реализация LinuxThreads, где каждая нить процесса имеет свой PID).

## ПРИМЕР
Эта программа может использоваться для демонстрации синтаксиса канала в файле /proc/sys/kernel/core_pattern. Следующий сеанс оболочки демонстрирует использование данной программы (при компиляции был создан исполняемый файл с именем core_pattern_pipe_test):

```
$ cc -o core_pattern_pipe_test core_pattern_pipe_test.c
$ su
Password:
# echo "|$PWD/core_pattern_pipe_test %p UID=%u GID=%g sig=%s" > \
/proc/sys/kernel/core_pattern
# exit
$ sleep 100
^\                     # type control-backslash
Quit (core dumped)
$ cat core.info
argc=5
argc[0]=</home/mtk/core_pattern_pipe_test>
argc[1]=<20575>
argc[2]=<UID=1000>
argc[3]=<GID=100>
argc[4]=<sig=3>
Total bytes in core dump: 282624
```

### Исходный код программы

```
/* core_pattern_pipe_test.c */
#define _GNU_SOURCE
#include <sys/stat.h>
#include <fcntl.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define BUF_SIZE 1024
int
main(int argc, char *argv[])
{

    int tot, j;

    ssize_t nread;

    char buf[BUF_SIZE];

    FILE *fp;

    char cwd[PATH_MAX];

    /* Изменяем наш текущий рабочий каталог на тот, что у

       упавшего процесса */

    snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]);

    chdir(cwd);

    /* Записываем вывод в файл "core.info" в этом каталоге */

    fp = fopen("core.info", "w+");

    if (fp == NULL)

        exit(EXIT_FAILURE);

    /* Показываем аргументы командной строки, переданные программе

       core_pattern */

    fprintf(fp, "argc=%d\n", argc);

    for (j = 0; j < argc; j++)

        fprintf(fp, "argc[%d]=<%s>\n", j, argv[j]);

    /* Подсчитываем байты стандартного ввода (дампа памяти) */

    tot = 0;

    while ((nread = read(STDIN_FILENO, buf, BUF_SIZE)) > 0)

        tot += nread;

    fprintf(fp, "Total bytes in core dump: %d\n", tot);

    fclose(fp);

    exit(EXIT_SUCCESS);
}
```

## СМОТРИТЕ ТАКЖЕ
bash(1), coredumpctl(1), gdb(1), getrlimit(2), mmap(2), prctl(2), sigaction(2), elf(5), proc(5), pthreads(7), signal(7), systemd-coredump(8)


title: dir_colors(5)

summary: файл настроек для утилиты dircolors(1)

text:
# dir_colors(5)

## ИМЯ
dir_colors - файл настроек для утилиты dircolors(1)

## ОПИСАНИЕ
Программа ls(1) использует переменную окружения LS_COLORS для определения цветов, которыми должны отображаться имена файлов. Эта переменная окружения обычно устанавливается командой типа:

eval `dircolors некий_путь/dir_colors`

Эта команда обычно находится в стандартном файле начальных настроек оболочки командной строки, например в /etc/profile или /etc/csh.cshrc. (Смотрите также dircolors(1).) Обычно здесь используется файл /etc/DIR_COLORS, и его настройки могут быть изменены файлом .dir_colors из каталога пользователя.

Данный файл настройки состоит из нескольких операторов, по одному в строке. Всё, что находится после символа решётки (#), считается комментарием (если этот символ находится в начале строки или перед ним находится как минимум один пробел). Пустые строки игнорируются.

Все операторы, появившиеся до первого оператора TERM, составляют глобальный раздел. Они действуют для всех типов терминалов. После глобального раздела находится один или более разделов, описывающих определённые терминалы. Он начинается с одного или более операторов TERM, который задаёт тип терминала (то же имя, что указывается в переменной окружения TERM). Для любого терминала глобальные настройки всегда можно перекрыть терминал-специфичными.

Распознаются следующие операторы (регистр букв неважен):

TERM тип_терминала

Начинает раздел, специфичный для терминала, и указывает, к какому типу терминала он применим. Можно указывать несколько операторов TERM, чтобы создать раздел, применимый к нескольким типам терминалов.

COLOR yes|all|no|none|tty

(Только для Slackware; игнорируется GNU dircolors(1).) Указывает, что расцветка должна быть всегда разрешена (yes или all), никогда не разрешена (no или none), или разрешена, только если вывод происходит на терминальное устройство (tty). По умолчанию no.

EIGHTBIT yes|no

(Только для Slackware; игнорируется GNU dircolors(1).) Указывает, разрешены ли по умолчанию восьмибитные символы ISO 8859. Из соображений совместимости можно также указывать 1 вместо yes или 0 вместо no. По умолчанию no.

OPTIONS параметры

(Только для Slackware; игнорируется GNU dircolors(1).) Добавляет параметры по умолчанию к командной строке ls. Здесь можно указать любой разрешённый параметр команды ls, причем нужно указывать начальный знак минус. Заметьте, что dircolors не проверяет, допустимы ли эти параметры.

NORMAL цвет

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

Синоним NORM.

FILE цвет

Задаёт цвет, используемый для обычных файлов.

DIR цвет

Задаёт цвет, используемый для каталогов.

LINK цвет

Задаёт цвет, используемый для символьных ссылок.

Синонимы: LNK, SYMLINK.

ORPHAN цвет

Задаёт цвет, используемый для нерабочих символьных ссылок (указывающих на несуществующие файлы). Если этот цвет не задан, то ls будет использовать вместо него цвет LINK.

MISSING цвет

Задаёт цвет, используемый для отсутствующих файлов (несуществующих файлов, на которые указывают символьные ссылки). Если этот цвет не задан, то ls будет использовать вместо него цвет FILE.

FIFO цвет

Задаёт цвет, используемый для FIFO (именованных каналов).

Синоним PIPE.

SOCK цвет

Задаёт цвет, используемый для сокетов.

DOOR цвет

(Поддерживается, начиная с fileutils 4.1) Задаёт цвет, используемый для файлов типа door (Solaris 2.5 и выше).

BLK цвет

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

Синоним BLOCK.

CHR цвет

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

Синоним CHAR.

EXEC цвет

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

SUID цвет

Задаёт цвет, используемый для файлов с установленным битом set-user-ID.

Синоним SETUID.

SGID цвет

Задаёт цвет, используемый для файлов с установленным битом set-group-ID.

Синоним SETGID.

STICKY цвет

Задаёт цвет, используемый для файлов с установленным закрепляющим (sticky) битом.

STICKY_OTHER_WRITABLE цвет

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

Синоним OWT.

OTHER_WRITABLE цвет

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

Синоним OWR.

LEFTCODE цвет

Задаёт левый код для не-ISO 6429 терминалов (см. ниже).

Синоним LEFT.

RIGHTCODE цвет

Задаёт правый код для не-ISO 6429 терминалов (см. ниже).

Синоним RIGHT.

ENDCODE цвет

Задаёт конечный код для не-ISO 6429 терминалов (см. ниже).

Синоним END.

*расширение цвет

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

.расширение цвет

То же самое, что и *.расширение. Задаёт цвет, используемый для файлов, чьи имена заканчиваются указанным .расширением. Заметьте, что точка входит в состав расширения, и из-за этого невозможно указать расширение, не начинающееся с точки, например ~ для резервных копий редактора emacs. Эта форма записи считается устаревшей.

### Цветовые последовательности ISO 6429 (ANSI)
Большинство цветных ASCII-терминалов в настоящее время используют цветовые последовательности ISO 6429 (ANSI), а многие распространённые терминалы, не поддерживающие цвет, включая xterm и широко используемый и клонируемый DEC VT100, распознают цветовые коды ISO 6429 и без последствий удаляют их из выходного потока или же эмулируют их. ls по умолчанию использует коды ISO 6429, если включена расцветка.

Цветовые последовательности ISO 6429 представляют собой последовательность чисел, разделённых точками с запятой. Самые распространенные коды:

0

восстановить цвет по умолчанию

1

яркие цвета

4

подчёркнутый текст

5

мигающий текст

30

чёрные символы

31

красные символы

32

зелёные символы

33

жёлтые (или коричневые) символы

34

синие символы

35

пурпурные символы

36

бирюзовые символы

37

белые (или серые) символы

40

чёрный фон

41

красный фон

42

зелёный фон

43

жёлтый (или коричневый) фон

44

синий фон

45

пурпурный фон

46

бирюзовый фон

47

белый (или серый) фон

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

ls использует следующие значения по умолчанию:

NORMAL

0

обычный (не имя файла) текст

FILE

0

обычный файл

DIR

32

каталог

LINK

36

символьная ссылка

ORPHAN

не определено

сломанная символьная ссылка

MISSING

не определено

отсутствующий файл

FIFO

31

именованный канал (FIFO)

SOCK

33

сокет

BLK

44;37

блочное устройство

CHR

44;37

символьное устройство

EXEC

35

исполняемый файл

Некоторые терминальные программы неправильно распознают настройки цвета по умолчанию. Если весь текст становится расцвеченным после того, как вы просматриваете листинг каталога, измените коды NORMAL и FILE на цифровые коды для нормального цвета текста и фона.

### Другие типы терминалов (расширенная настройка)
Если у вас есть терминал (или принтер!) с поддержкой цвета (или другими возможностями выделения), который использует другой набор кодов, вы всё равно сможете создать подходящие настройки. Для этого нужно использовать операторы LEFTCODE, RIGHTCODE и ENDCODE.

При выводе имени файла ls генерирует такую последовательность: LEFTCODE кода_типа RIGHTCODE имя_файла ENDCODE, где код_типа — цветовая последовательность, зависящая от типа или имени файла. Если ENDCODE не определён, то вместо него будет использоваться последовательность LEFTCODE NORMAL RIGHTCODE. Предназначением левого (LEFTCODE) и правого (RIGHTCODE) кодов является сокращение количества информации, которую нужно набирать (а также спрятать уродливые escape-последовательности от пользователя). Если они не подходят для вашего терминала, их можно выключить, поместив соответствующее ключевое слово на отдельной строке.

ЗАМЕЧАНИЕ: Если ENDCODE определён в глобальном разделе файла настроек, то его нельзя переопределить в разделе определённого терминала. Это означает, что все определения NORMAL не приведут ни к какому результату. Однако, можно использовать различные ENDCODE, что и приведёт к нужному результату.

### Экранированные последовательности
Для того, чтобы указать в цветовых последовательностях или расширениях имён файлов управляющие символы или пробелы, можно использовать либо нотацию в стиле языка C с помощью обратной косой черты, либо нотацию в стиле программы stty с помощью символа ^. Нотация в стиле языка C включает в себя такие символы:

\a

Звуковой сигнал (ASCII 7)

\b

Забой (ASCII 8)

\e

Экранирующий символ (ASCII 27)

\f

Прогон страницы (ASCII 12)

\n

Перевод строки (ASCII 10)

\r

Возврат каретки (ASCII 13)

\t

Табуляция (ASCII 9)

\v

Вертикальная табуляция (ASCII 11)

\?

Удаление (ASCII 127)

\nnn

Любой символ (восьмеричная запись)

\xnnn

Любой символ (шестнадцатеричная запись)

\_

Пробел

\\

Обратная косая черта (\)

\^

Крышка (^)

\#

Знак решетки (#)

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

## ФАЙЛЫ
/etc/DIR_COLORS

Общесистемный файл настройки

~/.dir_colors

Пользовательский файл настройки

Эта страница описывает формат файла dir_colors, который можно найти в пакете fileutils-4.1; другие версии могут немного отличаться.

## ЗАМЕЧАНИЯ
Значение LEFTCODE и RIGHTCODE, используемые по умолчанию терминалами ISO 6429:

LEFTCODE

\e[

RIGHTCODE

m

По умолчанию значение ENDCODE не определено.

## СМОТРИТЕ ТАКЖЕ
dircolors(1), ls(1), stty(1), xterm(1)