What is nss linux

What is nss linux

Linux – система многопользовательская. По умолчанию, большинство дистрибутивов используют «классический» набор файлов в которых хранится информация о пользователях и группах: /etc/passwd , /etc/group , /etc/shadow , /etc/gshadow . Во многих ситуациях этого вполне достаточно, но иногда возникает необходимость в интеграции Linux в более или менее чужеродное, либо просто распределенное окружение, и именно в этот момент к нам на помощь приходят такая интересная подсистема, как NSS – Name Service Switch. Основная задача NSS – создать модульное окружение для управления пользователями. Реализовано это посредством загружаемых библиотек. Основные вызовы NSS реализованы в библиотеке libc, а libc в свою очередь загружает и вызывает бакэнды NSS:

При инициализации программы, так или иначе связанной с NSS, загружаются основная библиотека libc.so , которая считывает конфигурацию из файла /etc/nsswitch.conf , после чего также загружаются те библиотеки NSS, которые указаны в этом файле.

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

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

Пример файла nsswitch.conf :

В данном примере указано, что для определения имен пользователей и групп используются сначала текстовые файлы и затем LDAP, для определения имен компьютеров и IP-адресов используются сначала текстовые файлы и затем DNS, для определения алиасов и настроек автоматического монтирования каталогов используются сначала текстовые файлы и затем служба NIS+.

Библиотеки бакэндов системы NSS хранятся в файлах libnss_ XXX .so , где XXX – это имя бакэнда. Например libnss_files.so – это бакэнд NSS использующий в качестве источника данных текстовые файлы, libnss_db.so – бакэнд использующий файлы BerkleyDB, libnss_ldap.so – бакэнд позволяющий хранить данные в каталоге LDAP. Как правило, каждый бакэнд имеет свои дополнительные конфигурационные файлы.

Как следствие, если у вас возникла необходимость использовать вашу Linux-систему в сетевом или чужеродном окружении и обеспечить ее интеграцию с ним, вы можете воспользоваться NSS и получить доступ к информации через соответствующий бакэнд – например, для интеграции в среду Solaris, вы можете воспользоваться бакэндом NIS/NIS+, для интеграции в ActiveDirectory – бакэндом LDAP.

При этом модульность NSS позволяет вам объединять различные источники данных – например, использовать текстовые файлы и DNS для определения имен компьютеров, NIS для определения имен протоколов и сервисов, и текстовые файлы и LDAP для определения имен и идентификаторов пользователей и групп.

Подсистема PAM (Pluggable Authentification Modules) идейно очень схожа с NSS, но отличается от нее назначением. Основная задачам PAM – аутентификация пользователей (проверка паролей, прав доступ, ограничений и так далее). Как и NSS, PAM состоит из набора основных библиотек и бакэндов, причем необходимые бакэнды, порядок их вызова и некоторые опциональные параметры определяются в конфигурационных файлах PAM, обычно они расположены в каталоге /etc/pam.d . Главным отличием PAM от NSS (кроме естественно назначения) является то, что PAM является не составной и неотъемлемой частью libc, а отдельным множеством библиотек.

Основная часть стандартных утилит UNIX для управления пользователями и группами и получения информации о них, в большинстве дистрибутивов Linux общего назначения, адаптирована и собрана с поддержкой NSS и PAM. К таким утилитам относятся passwd , chsh , chfn , id , who и другие. NSS также используется даже такими утилитами как ls , find , ps – то есть всеми теми программами, которые отображают имя пользователя. Соответственно, если программа запрашивает у пользователя пароль – скорее всего она использует и NSS, и PAM (например XDM или GDM). Большинство программ в чьи функции входит обработка почты также используют NSS. Соответственно, можно уверенно говорить что подсистемы NSS и PAM и базовые знания об их предназначении на сегодняшний день являются необходимыми для администратора Linux-систем.

Источник

nss(5) — Linux man page

nss — Name Service Switch configuration file

Description

Each call to a function which retrieves data from a system database like the password or group database is handled by the Name Service Switch implementation in the GNU C library. The various services provided are implemented by independent modules, each of which naturally varies widely from the other.

The default implementations coming with the GNU C library are by default conservative and do not use unsafe data. This might be very costly in some situations, especially when the databases are large. Some modules allow the system administrator to request taking shortcuts if these are known to be safe. It is then the system administrator’s responsibility to ensure the assumption is correct.

There are other modules where the implementation changed over time. If an implementation used to sacrifice speed for memory consumption it might create problems if the preference is switched.

The /etc/default/nss file contains a number of variable assignments. Each variable controls the behavior of one or more NSS modules. White spaces are ignored. Lines beginning with ‘#’ are treated as comments.

The variables currently recognized are: NETID_AUTHORITATIVE = TRUE|FALSE If set to TRUE, the NIS backend for the initgroups(3) function will accept the information from the netid.byname NIS map as authoritative. This can speed up the function significantly if the group.byname map is large. The content of the netid.byname map is used as is. The system administrator has to make sure it is correctly generated. SERVICES_AUTHORITATIVE = TRUE|FALSE If set to TRUE, the NIS backend for the getservbyname(3) and getservbyname_r(3) functions will assume that the services.byservicename NIS map exists and is authoritative, particularly that it contains both keys with /proto and without /proto for both primary service names and service aliases. The system administrator has to make sure it is correctly generated. SETENT_BATCH_READ = TRUE|FALSE If set to TRUE, the NIS backend for the setpwent(3) and setgrent(3) functions will read the entire database at once and then hand out the requests one by one from memory with every corresponding getpwent(3) or getgrent(3) call respectively. Otherwise each getpwent(3) or getgrent(3) call might result in a network communication with the server to get the next entry.

Files

Example

The default configuration corresponds to the following configuration file:

Источник

NSS-3.70

Introduction to NSS

The Network Security Services ( NSS ) package is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. This is useful for implementing SSL and S/MIME or other Internet security standards into an application.

This package is known to build and work properly using an LFS-11.0 platform.

Package Information

Download MD5 sum: 1624b400d750f4278f46bbda161223a0

Download size: 81 MB

Estimated disk space required: 310 MB (add 163 MB for tests)

Estimated build time: 2.0 SBU (with parallelism=4, add 19 SBU for tests)

Additional Downloads

NSS Dependencies

Required

Recommended

Installation of NSS

Install NSS by running the following commands:

To run the tests, execute the following commands:

Some information about the tests:

HOST=localhost and DOMSUF=localdomain are required Without these variables, a FQDN is required to be specified and this generic way should work for everyone.

The tests take an extremely long time to run. If desired there is information in the all.sh script about running subsets of the total test suite.

When interrupting the tests, the test suite fails to spin down test servers that are run. This leads to an infinite loop in the tests where the test suite tries to kill a server that doesn’t exist anymore because it pulls the wrong PID.

Test suite results (in HTML format!) can be found at ../../test_results/security/localhost.1/results.html

Now, as the root user:

Command Explanations

BUILD_OPT=1 : This option is passed to make so that the build is performed with no debugging symbols built into the binaries and the default compiler optimizations are used.

NSPR_INCLUDE_DIR=/usr/include/nspr : This option sets the location of the nspr headers.

USE_SYSTEM_ZLIB=1 : This option is passed to make to ensure that the libssl3.so library is linked to the system installed zlib instead of the in-tree version.

ZLIB_LIBS=-lz : This option provides the linker flags needed to link to the system zlib .

$([ $(uname -m) = x86_64 ] && echo USE_64=1) : The USE_64=1 option is required on x86_64 , otherwise make will try (and fail) to create 32-bit objects. The [ $(uname -m) = x86_64 ] test ensures it has no effect on a 32 bit system.

([ -f /usr/include/sqlite3.h ] && echo NSS_USE_SYSTEM_SQLITE=1) : This tests if sqlite is installed and if so it echo s the option NSS_USE_SYSTEM_SQLITE=1 to make so that libsoftokn3.so will link against the system version of sqlite.

NSS_DISABLE_GTESTS=1 : If you don’t need to run NSS test suite, append this option to make command, to prevent the compilation of tests and save some build time.

Источник

Resolve IP адресов в Linux: понятное и детальное описание

Настройка сетевого взаимодействия сервисов не самая простая задача и часто осуществляется без глубокого понимания как требуется настраивать систему и какие настройки на что влияют. После миграции сервисов в docker контейнерах с centos 6 на centos 7 я столкнулся со странным поведением вебсервера: он пытался присоединиться к сервису по IPv6, а сервис же слушал только IPv4 адрес. Стандартный совет в такой ситуации — отключить поддержку IPv6. Но это не поможет в ряде случаев. Каких? В этой статье я задался целью собрать и детально объяснить как приложения resolve ‘ят адреса.

Публикация будет полезна начинающим администраторам и разработчикам.

Прочитав эту статью, вы узнаете:

• какой алгоритм в Linux для резолва хостнеймов;
• как переопределить логику определения хостнеймов;
• какие функции и библиотеки использует ОС;
• какие ловушки существуют при конфигурировании и как их не допускать;

У операционной системы Linux есть несколько источников для определения адреса по hostname. Весь необходимый функционал для определения находится в GNU C Library (glibc). glibc является по-сути фреймворком и реализовывает множество полезных функций для разработчика, предоставляя свой API для упрощения разработки. Среди прочего, glibc имплементирует POSIX. Такие функции как open , read , write , malloc , printf , getaddrinfo , dlopen , pthread_create , crypt , login , exit для Linux систем предоставляет именно glibc.

Известные многим утилиты host , dig и nslookup используют glibc, но поставляются отдельно.

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

Теперь, когда у разработчика есть возможность вызвать функцию семейства getaddrinfo из glibc для определения адреса, то возникает потребность конфигурировать возвращаемые значения. Например, использовать ли сперва /etc/hosts или запрос к DNS-серверу. В glibc подобное конфигурирование производится с помощью схемы под названием Name Service Switch (NSS).

Если объяснять на пальцах, то NSS позволяет задавать базы данных и очередность поиска в этих базах для предоставления сервиса. В нашем случае, сервис — это поиск по hostname, а базой данных может выступать /etc/hosts или DNS сервер. Это не единственный сервис настраиваемый посредством NSS, предоставляются сервисы mail алиасов, сервис поиска пользователей и групп. Ознакомится со списком можно в руководстве.

Благодаря NSS можно без пересборки приложений, в рантайме, конфигурировать упомянутые базы данных. Производится конфигурирование в файле /etc/nsswitch.conf . Ниже пример конфига из стандартного /etc/nsswitch.conf в Centos 7.

files, dns и myhostname являются алиасами баз данных для поиска. files на большинстве систем подразумевает использование /etc/hosts , dns база — это DNS-сервер к которому будет осуществляться запрос поиска hostname, а myhostname — это самая необычная база, о существовании которой мало кто знает и она не является частью стандартной поставки в glibc. В некоторых дистрибутивах присутствует еще и база mdns4_minimal. Ниже по тексту предоставлен разбор этих баз данных.

Базы используются в том порядке в котором они обьявлены в /etc/nsswitch.conf и если в текущей базе запись найдена, то происходит выход из цепочки и возврат результата. При отсутствии результата происходит переход к следующей базе в списке. Если ни в одной базе не найден результат, то такой ответ и дается на запрос glibc функции getaddrinfo . Поведение перехода к следующей базе и условия такого перехода можно дополнительно конфигурировать, например, при недоступности DNS (не путать с отсутствием записи) завершить цепочку. Понятное и простое объяснение принципа настройки условий для /etc/nsswitch.conf даны в этой статье.

База files, а в частности /etc/hosts , из коробки в Centos 7 выглядит следующим образом:

Можно отметить, что для localhost имеются две записи: IPv4 и IPv6 адрес. Это может сыграть злую шутку и в конце материала я расскажу почему.

База dns при определении адреса использует name server указанный в конфиге /etc/resolv.conf . Вот пример моего /etc/resolv.conf на хост системе:

Name server’а используются тоже по цепочке и в порядке их объявления. В моем случае, первым выступает локальный DNS сервер (я использую dnsmasq) для задания локальных адресов .priv зон. Если находится совпадение, то возвращается адрес из локальной сети. Все остальные запросы отправляются на основной DNS сервер с адресом 192.168.100.1 .

База myhostname присутствует в поставке Centos и Ubuntu, но не является частью glibc . Не зная этого факта я потратил много времени пытаясь выяснить почему мне возвращаются IPv6 адреса для определения хоста. Он работает следующим образом:

• При запросе локального хостнейма (того что возвращает команда hostname ) плагин возвращает все IP адреса публичных интерфейсов (т.е. все кроме loopback), при отсутствии таких интерфейсов возвращается IPv4 адрес 127.0.0.2 и IPv6 адрес ::1 ;
• При запросе хостнейма localhost или localhost.localdomain возвращает IPv4 адрес 127.0.0.1 и IPv6 адрес ::1 ;
• При запросе хостнейма оканчивающегося на .localhost или .localhost.localdomain возвращает IPv4 адрес 127.0.0.1 и IPv6 адрес ::1 ;

В мануале еще пишут про особую логику с обработкой хостнейма _gateway, но видимо это какой-то патч, так как с Centos 7 у меня он не завелся.

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

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

Обычно администраторы проверяют хостнейм используя команду host. Это некорректно, так host, как и dig, используют только DNS резолвинг, но не используют NSS. Nginx, например, использует функцию getaddrinfo, а она использует NSS. Это приводит к тому, что вбитый в /etc/hosts хостнейм может работать с nginx, но не резолвится иными способами. Куда хуже, когда в /etc/hosts вбиты IPv6 адрес для хостнейма, а в настройках DNS возвращается только IPv4 адрес. В этом случае, администратор может проверить что команда host возвращает только IPv4 адрес и успокоится, а потом приложение использующее getaddrinfo из glibc запустится и найдет для того же хостнейма IPv4 и IPv6 адрес. Источник ошибок…

Для проверки результатов возвращаемой каждой из баз документация рекомендует воспользоваться утилитой getent.

Ниже немного примеров работы с getent с включенным IPv6.

В /etc/nsswitch.conf содержится следующая цепочка баз:

В /etc/hosts содержится следующее инфо

Команда getent ahosts покажет список всех адресов которые удалось найти. С такими настройками она выведет следующее:

Команда позволяет точечно опросить конкретную базу и выяснить что срезолвит база. Рассмотрим для каждой базы возвращаемые значения:

Если убрать из /etc/hosts строки для localhost, то вывод видоизменится:

Теперь база dns и myhostname возвращает ответы, а база files не содержит данных. Для DNS запросов используется неймсервер конфигурируемый в /etc/resolv.conf в моем контейнере, например

На хост машине установлен dnsmasq который проксирует и кэширует ответы DNS серверов. Ответ от DNS будет зависеть от настроек DNS сервера к которому поступил запрос. RFC 1912 рекомендует в пункте 4.1 сконфигурировать DNS сервера таким образом, чтобы localhost указывал на 127.0.0.1.

Certain zones should always be present in nameserver configurations:

These are set up to either provide nameservice for «special»
addresses, or to help eliminate accidental queries for broadcast or
local address to be sent off to the root nameservers. All of these
files will contain NS and SOA records just like the other zone files
you maintain, the exception being that you can probably make the SOA
timers very long, since this data will never change.

The «localhost» address is a «special» address which always refers to
the local host. It should contain the following line:

В моем случае, dnsmasq из коробки содержит записи для localhost, как и рекомендует RFC.

Отключается это либо удалением записей из /etc/hosts на самом DNS сервере, либо же включением опции no-hosts в /etc/dnsmasq.conf .

После включения опции getent для базы myhostname вернет непустой результат, но как и отмечалось выше, с включенным myhostname будет возвращаться IPv4 и IPv6 адрес. На системах со статическими IP адресами можно смело выключить myhostname плагин и конфигурировать локальные хосты с использованием /etc/hosts . Альтернативный вариант — это отключение IPv6.

Статус IPv6 на сервере можно получить из параметров ядра. Значение 0 возвращается при включенном IPv6, а 1 при выключенном.

В выводе ifconfig интерфейсы слушающие IPv6 содержат строчку inet6. Ниже пример вывода с выключенным и включенным IPv6 соответственно:

Выключить IPv6 можно вызовом

Что изменится после выключения? Я откатил все конфиги на стандартные: в /etc/hosts присутствует localhost с адресами IPv4 и IPv6, в dnsmasq выключена опция no-hosts . Отключил IPv6 командами выше и вывод getent стал следующим:

Воу, в первом выводе у нас дублируется адрес 127.0.0.1. Чтобы разобраться почему так происходит стоит обратиться к исходному коду glibc и к коду утилиты getent. Ниже кусок кода утилиты getent.

Флаг AI_V4MAPPED функции getaddrinfo производит маппинг IPv6 адресов на IPv4 если не были найдены IPv6 адреса в результате опроса базы. Флаг AI_ADDRCONFIG вынудит getaddrinfo проверить наличие IPv6/IPv4 адресов сконфигурированных в системе и в случае отсутствия хотя бы одного IPv6/IPv4 адреса не будет возвращаться IPv6/IPv4 независимо от того что ответит конкретная база.

Поскольку у getent включены оба флага, а в /etc/hosts присуствуетя для localhost адреса 127.0.0.1 и ::1 , то getaddrinfo получит из NSS базы hosts (в примере выше мы обсуждали именно эту базу), адреса 127.0.0.1 и ::1 , затем не обнаружив ни одного IPv6 адреса в системе (выключены параметрами ядра) и произведет маппинг ::1 -> 127.0.0.1 .

Чтобы лучше понять эту концепцию, приведу примеры с выводом getaddrinfo на той же системе, с разными настройками ai_flags и ai_family. В /etc/hosts включены для localhost IPv4 и IPv6 адреса.
Исходный код можно найти на моем github.

Из вывода видно, что с _aifamily равным _AIUNSPEC (возвращать и IPv4, и IPv6) и без AI_ADDRCONFIG флага getaddrinfo возвращает два адреса, IPv4 и IPv6, что многие администраторы не ожидают увидеть. Это происходит независимо от того выключен ли IPv6 в параметрах ядра. Если в /etc/hosts убрать адрес ::1 , то из вывода getaddrinfo (с флагом AF_UNSPEC ) вовсе исчезнут IPv6 адреса.

С включенным IPv6 и наличием ::1 в /etc/hosts будет возвращаться IPv4 и IPv6. Для предотвращения возврата адреса IPv6 требуется закомментировать IPv6 адрес в /etc/hosts . Если адреса будут найдены в /etc/hosts , то в dns и myhostname базу glibc не полезет.

Осталось проверить как ведет себя getaddrinfo для dns базы. Для этого оставлю в /etc/nsswitch.conf для hosts только dns базу и порезолвлю google.com. Вывод ниже с включенным IPv6.

А вот вывод с выключенным IPv6:

Как видно, ситуация с AI_ADDRCONFIG очень похожа.

Напоследок приведу пример как не учитывая все вышесказанное вляпаться в проблемы. IPv6 включен, /etc/nsswitch.conf стандартный.

Что вернет host localhost или dig ANY localhost ? Что вернет getaddrinfo , например, с флагами как у nginx?

nginx будет пытаться подключаться к двум адресам: 127.0.0.1 и ::1 , а приложение может и не ожидать такого. Источник для ошибок.

Какой можно сделать вывод из всего написанного?

1. Если вы разрабатываете приложение работающее с сетью, то учитывайте, что IPv6 может быть отключен;
2. При настройке сервера учитывайте наличие NSS и очередности проверок, используйте getent или мой код для проверки;
3. Если неизвестно как работает приложение, то при наличии исходных кодов можно посмотреть с какими флагами резолвятся
   адреса и сверить с настройками системы;
4. Если исходных кодов нет, то можно по поведению в выводе strace сделать предположение об используемых флагах.

Источник