Какой из перечисленных портов может быть занят процессом linux без прав суперпользователя

Обновлено: 21.11.2024

В этом разделе содержатся необязательные процедуры для настройки хостов Linux для лучшей работы с Docker.

Управление Docker от имени пользователя без полномочий root

Демон Docker привязывается к сокету Unix, а не к TCP-порту. По умолчанию этот сокет Unix принадлежит пользователю root, и другие пользователи могут получить к нему доступ только с помощью sudo . Демон Docker всегда запускается от имени пользователя root.

Если вы не хотите предварять команду docker sudo , создайте группу Unix с именем docker и добавьте в нее пользователей. Когда демон Docker запускается, он создает сокет Unix, доступный членам группы docker.

Предупреждение

Группа docker предоставляет привилегии, эквивалентные привилегиям пользователя root. Подробнее о том, как это влияет на безопасность вашей системы, см. в разделе Поверхность атаки Docker Daemon.

Чтобы создать группу Docker и добавить своего пользователя:

Создайте группу Docker.

Добавьте пользователя в группу Docker.

Выйдите из системы и войдите снова, чтобы повторно оценить ваше членство в группе.

При тестировании на виртуальной машине может потребоваться перезапустить виртуальную машину, чтобы изменения вступили в силу.

В настольной среде Linux, такой как X Windows, полностью завершите сеанс, а затем войдите снова.

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

Убедитесь, что вы можете запускать команды docker без sudo .

Эта команда загружает тестовый образ и запускает его в контейнере. Когда контейнер запускается, он печатает сообщение и завершает работу.

Если вы изначально запускали команды Docker CLI с помощью sudo перед добавлением пользователя в группу docker, вы можете увидеть следующую ошибку, указывающую на то, что ваш каталог ~/.docker/ был создан с неправильными разрешениями из-за команд sudo.< /p>

Чтобы решить эту проблему, либо удалите каталог ~/.docker/ (он будет воссоздан автоматически, но все пользовательские настройки будут потеряны), либо измените его владельца и права доступа с помощью следующих команд:

Настройте Docker для запуска при загрузке

Большинство современных дистрибутивов Linux (RHEL, CentOS, Fedora, Debian, Ubuntu 16.04 и выше) используют systemd для управления запуском служб при загрузке системы. В Debian и Ubuntu служба Docker настроена на запуск при загрузке по умолчанию. Чтобы автоматически запускать Docker и Containerd при загрузке других дистрибутивов, используйте следующие команды:

Чтобы отключить это поведение, используйте вместо этого команду отключить.

Использовать другой механизм хранения

Информацию о различных механизмах хранения см. в разделе Драйверы хранилища. Механизм хранения по умолчанию и список поддерживаемых механизмов хранения зависят от дистрибутива Linux вашего хоста и доступных драйверов ядра.

Настроить драйвер ведения журнала по умолчанию

Docker позволяет собирать и просматривать данные журнала из всех контейнеров, запущенных на узле, с помощью ряда драйверов ведения журнала. Драйвер ведения журнала по умолчанию, json-file, записывает данные журнала в файлы в формате JSON в файловой системе хоста. Со временем эти файлы журналов увеличиваются в размере, что может привести к исчерпанию дисковых ресурсов.

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

Настройте, где демон Docker прослушивает соединения

По умолчанию демон Docker прослушивает подключения к сокету UNIX, чтобы принимать запросы от локальных клиентов. Можно разрешить Docker принимать запросы от удаленных хостов, настроив его на прослушивание IP-адреса и порта, а также сокета UNIX. Для получения более подробной информации об этом параметре конфигурации см. раздел «Привязать Docker к другому хосту/порту или сокету unix» в справочной статье Docker CLI.

Защитите свое соединение

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

В Linux и других UNIX-подобных системах вы должны быть root (иметь права суперпользователя), чтобы прослушивать порты TCP или UDP ниже 1024 (общеизвестные порты).< /p>

Это ограничение на порт 1024 является мерой безопасности. Но она основана на устаревшей модели безопасности и сегодня дает лишь ложное ощущение безопасности и создает дыры в безопасности.

Ограничение порта 1024 вынуждает вас запускать все сетевые демоны с
правами суперпользователя, что может открыть дыры в безопасности.Без ограничения порта 1024 большинство сетевых демонов (кроме sshd) можно было бы запускать без привилегий суперпользователя. Некоторые демоны пытаются исправить эту потенциальную дыру в безопасности, сбрасывая привилегии суперпользователя после привязки к порту, но вам все равно нужно запускать демона как root. И это не работает, если демон написан на Java, что довольно популярно для веб-серверов.

Сегодня типичный Linux-компьютер не используется таким образом, что делает ограничение порта 1024 актуальным. Либо вы используете его как настольный клиент (рабочая станция) только с одним пользователем, имеющим доступ суперпользователя через sudo . В настольном случае ограничение является источником разочарования, поскольку вам приходится использовать sudo чаще, чем необходимо.

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

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

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

Я не виню тех, кто изобрел ограничение на порт 1024, это была естественная и важная функция безопасности, учитывая, как машины UNIX использовались в 1970-х и 1980-х годах. Типичная машина UNIX позволяла группе ненужных полностью доверенных людей входить в систему и делать что-то. Вы не хотите, чтобы эти ненадежные пользователи могли установить собственный демон, выдающий себя за хорошо известную службу, такую как telnet или ftp, поскольку это может быть использовано для кражи паролей и других неприятных вещей.

Ограничение порта 1024 является частью той же модели безопасности, которая дала нам аутентификацию rlogin. Эта модель безопасности основана на предположении, что каждой машине (но не каждому пользователю) в сети можно доверять, что только доверенные пользователи имеют root-доступ к любой машине, подключенной к сети, и что все машины, подключенные к сети, имеют одинаковое ограничение на порт 1024.< /p>

Хорошо известно, что сегодня эта модель безопасности устарела и совершенно бесполезна в общедоступном Интернете. Практически любой может подключить компьютер к общедоступному Интернету и получить root-доступ, и есть по крайней мере одна популярная операционная система без этого ограничения порта 1024 — Microsoft Windows.

В связи с этим ни один здравомыслящий человек сегодня не использует аутентификацию rlogin в сети, подключенной к Интернету (по крайней мере, без защиты с помощью тщательно настроенного брандмауэра). Но ограничение порта 1024 все еще существует в Linux и большинстве других систем стиля UNIX. Интересно, почему. Не пора ли объявить лимит порта 1024 тоже устаревшим и убрать его?

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

В FreeBSD есть пара параметров sysctl, позволяющих настроить (или эффективно удалить) это ограничение на число портов: net.inet.ip.portrange.reservedlow и net.inet.ip.portrange.reservedhigh. Было бы неплохо, если бы нечто подобное было реализовано в Linux (и в других UNIX-подобных системах). Вероятно, не очень полезно иметь возможность регулировать нижнюю часть диапазона, ее можно зафиксировать на 0.

Но было бы очень полезно скорректировать верхнюю часть диапазона от текущего значения 1023. Если вы установите его на 79, вы сможете запускать веб-сервер без привилегий суперпользователя, но только root может привязываться к нижним портам (таким как как ssh).

Очень раздражает наличие этого ограничения в моем окне разработки, когда кроме меня никогда не будет никаких пользователей.

Мне известны стандартные обходные пути, но ни один из них не делает именно то, что мне нужно:

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

Есть ли какая-нибудь простая переменная sysctl, позволяющая процессам без полномочий root связываться с "привилегированными" портами (порты меньше 1024) в Linux, или мне просто не повезло?

EDIT: в некоторых случаях для этого можно использовать возможности.

Потому что в данном случае я использовал IPv6, поэтому некоторые "обычные" обходные пути (authbind и iptables REDIRECT) у меня не работали.

25 ответов 25

Хорошо, спасибо людям, которые указали на систему возможностей и возможности CAP_NET_BIND_SERVICE. Если у вас недавнее ядро, его действительно можно использовать для запуска службы без полномочий root, но привязать низкие порты. Короткий ответ: да:

И затем каждый раз, когда программа будет выполняться после этого, она будет иметь возможность CAP_NET_BIND_SERVICE. setcap находится в пакете Debian libcap2-bin .

Теперь предостережения:

. Прочитайте это долго и внимательно, если вы собираетесь использовать возможности в производственной среде. Есть некоторые действительно сложные детали того, как возможности наследуются при вызовах exec(), которые подробно описаны здесь. : Документ, который впервые указал мне на setcap.

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

Да, @C.Ross, поскольку его нужно будет применить к /usr/bin/java, а затем открыть возможность для любого приложения Java, работающего в системе. Жаль, что возможности также не могут быть установлены для каждого пользователя.

Сохраняется ли параметр setcap при перезагрузке; если нет, есть ли стандартное место для размещения этого правила, чтобы оно запускалось при запуске системы? Поможет ли файл /etc/security/capability.conf в Debian/Ubuntu?

Вы можете выполнить перенаправление портов. Это то, что я делаю для сервера политик Silverlight, работающего на компьютере с Linux

@joeytwiddle Думаю, дело в скрипте, который запускает (запускает) ваш сервер, но могу ошибаться. Я тоже хотел бы знать :P

@CamiloMartin Опять же, документация Debian, ссылка на которую была указана в вопросе, рекомендует поместить его в сценарий вашего брандмауэра или создать его в /etc/network/if-up.d/firewall .

Похоже, что в старых ядрах это не поддерживалось для IPv6. Но, по-видимому, он поддерживается в ip6tables v1.4.18 и ядре Linux v3.8.

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

Интересно, что это не работает в последних версиях Linux (может быть, только в Ubuntu) без установленного CAP_SETUID. Поэтому, если вам нужен setuid, вам все равно придется установить эту возможность.

Правильный способ сделать это — удалить привилегии root. Хотя нет необходимости устанавливать setuid, если у вас запущена служба init/upstart/systemd.

Если вы зададите бинарный setuid, он будет запущен как корневой процесс. Однако вопрос заключается в том, как это сделать, не запуская двоичный файл как корневой процесс. Это решение является ответом на другой вопрос, а именно: «Как непривилегированный пользователь может привязать процесс к привилегированному порту», но это не вопрос, ИМХО?

Обновление 2017:

*Отказ от ответственности (обновление на 2021 г.): обратите внимание, что authbind работает через LD_PRELOAD, который используется только в том случае, если ваша программа использует LIBC, что (или может) быть не так, если ваша программа скомпилирована с помощью GO или любого другого компилятора, который избегает C. Если вы используете go, установите параметр ядра для защищенного диапазона портов, см. конец сообщения.

Authbind намного лучше, чем CAP_NET_BIND_SERVICE или собственное ядро.

CAP_NET_BIND_SERVICE предоставляет доверие двоичному файлу, но не обеспечивает контроль над доступом к каждому порту.
Authbind предоставляет доверие пользователю/группе и обеспечивает контроль над доступом к каждому порту, а также поддерживает как IPv4, так и IPv6 (в последнее время была добавлена поддержка IPv6).

Установить: apt-get install authbind

Настройте доступ к соответствующим портам, например 80 и 443 для всех пользователей и групп:

sudo touch /etc/authbind/byport/80
sudo touch /etc/authbind/byport/443
sudo chmod 777 /etc/authbind/byport/80
sudo chmod 777 /etc/authbind/byport/443

Выполните вашу команду через authbind
(необязательно указав --deep или другие аргументы, см. справочную страницу):

Вдогонку к невероятной (=не рекомендуется, если вы не знаете, что делаете) рекомендации Джошуа взломать ядро:

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

Просто. С нормальным или старым ядром вы этого не сделаете.
Как указывали другие, iptables может перенаправлять порт.
Как уже отмечалось другими, CAP_NET_BIND_SERVICE также может выполнять эту работу.
Конечно, CAP_NET_BIND_SERVICE потерпит неудачу, если вы запустите свою программу из скрипта, если вы не установите ограничение на интерпретатор оболочки, что бессмысленно, вы можете просто запустить свою службу от имени пользователя root.
например. для Java вы должны применить его к JAVA JVM

Я также уверен, что xinetd — не лучшая идея.
Но поскольку оба метода являются хакерами, почему бы просто не снять ограничение, сняв ограничение?
Никто не говорил, что вам нужно запускать обычное ядро, так что вы можете просто запустить свое собственное.

Вы просто загружаете исходный код последнего ядра (или того, что у вас есть сейчас). После этого вы переходите к:

Ищите эту строку

и измените его на

Это уже все.
Скомпилируйте ядро и установите его.
Перезагрузка.
Готово — это дурацкое ограничение ИСЧЕЗЛО, и это также работает для скриптов.

Вот как вы скомпилируете ядро:

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

Примечание. В последнее время обновление ядра больше не требуется.
Теперь вы можете установить

И если это приведет к ошибке, просто отредактируйте /etc/sysctl.conf с помощью nano и установите там параметр для сохранения после перезагрузки.

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

Возможно, более безопасным способом будет изменить chmod 777 /etc/authbind/byport/80 на chmod 544 /etc/authbind/byport/23, чем chown login:group /etc/authbind/byport/23< /p>

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

(Крайний вариант, не рекомендуется).

В net/ipv4/af_inet.c удалите две строки, которые читаются

и ядро больше не будет проверять привилегированные порты.

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

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

Почему-то никто не упомянул о понижении sysctl net.ipv4.ip_uncitationd_port_start до нужного вам значения. Пример: нам нужно привязать наше приложение к порту 443.

Кто-то может сказать, что существует потенциальная проблема безопасности: непривилегированные пользователи теперь могут подключаться к другим привилегированным портам (444-1024). Но вы можете легко решить эту проблему с помощью iptables, заблокировав другие порты:

Сравнение с другими методами. Этот метод:

с какого-то момента (IMO) даже более безопасно, чем установка CAP_NET_BIND_SERVICE/setuid, поскольку приложение вообще не использует setuid, даже частично (возможности на самом деле есть). Например, чтобы получить дамп ядра приложения с поддержкой возможностей, вам нужно будет изменить sysctl fs.suid_dumpable (что приведет к другим потенциальным проблемам безопасности). Кроме того, когда установлен CAP/suid, каталог /proc/PID принадлежит пользователю root, поэтому ваш пользователь без полномочий root не будет иметь полной информации/контроля над запущенным процессом, например, пользователь не сможет (в общем случае) определить, какие соединения принадлежат приложению через /proc/PID/fd/ (netstat -aptn | grep идентификатор).
недостаток безопасности: пока ваше приложение (или любое приложение, использующее порты 443–1024) по какой-то причине не работает, порт может занять другое приложение. Но эта проблема также может быть применена к CAP/suid (если вы установите его на интерпретаторе, например, java/nodejs) и iptables-redirect. Используйте метод systemd-socket, чтобы исключить эту проблему. Используйте метод authbind, чтобы разрешить только специальную привязку пользователя.
не требуется настраивать CAP/suid каждый раз при развертывании новой версии приложения.
не требует поддержки/модификации приложения, как метод systemd-socket.
не требует пересборки ядра (если текущая версия поддерживает этот параметр sysctl)
не выполняет LD_PRELOAD, как метод authbind/privbind, это потенциально может повлиять на производительность, безопасность и поведение (так ли это? Не проверял). В остальном authbind действительно гибкий и безопасный метод.
превышает производительность метода REDIRECT/DNAT iptables, поскольку он не требует преобразования адресов, отслеживания состояния подключения и т. д. Это заметно только на высоконагруженных системах.

В зависимости от ситуации я бы выбрал между sysctl, CAP, authbind и iptables-redirect. И это здорово, что у нас так много вариантов.

Спасибо за отличный ответ! Похоже, что эта функция впервые появилась в Linux 4.11 в апреле 2017 года, поэтому в 2009 году, когда я впервые задал этот вопрос, ее еще не было. Я также провел быстрый тест, и, похоже, он работает и для IPV6, даже несмотря на то, что в имени sysctl есть «ipv4».

Вы можете настроить локальный туннель SSH, например, если вы хотите, чтобы порт 80 связывал ваше приложение с портом 3000:

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

Я ожидаю, что это будет умеренно дорого и не будет хорошей идеей в любой ситуации, связанной с производительностью, но я не могу быть уверен, не протестировав это. Шифрование SSH стоит ненулевой суммы.

Вы выполняете шифрование и расшифровку только для перемещения данных на другой порт на том же компьютере? Кроме того, это не работает для трафика UDP.

Современный Linux поддерживает /sbin/sysctl -w net.ipv4.ip_uncitationd_port_start=0 .

Это самый простой способ, и он просто РАБОТАЕТ.. Спасибо, приятель.. Я только что вошел, чтобы поблагодарить вас.. Мне не нужны сложные ответы..

Я знаю, что это старый вопрос, но теперь, с недавними (>= 4.3) ядрами, наконец-то появился хороший ответ на этот вопрос — возможности окружения.

Быстрый ответ — взять копию последней (еще не выпущенной) версии libcap из git и скомпилировать ее. Скопируйте полученный бинарный файл progs/capsh куда-нибудь (хорошим выбором будет /usr/local/bin). Затем, как root, запустите свою программу с помощью

По порядку мы

Заявляем, что при смене пользователей мы хотим сохранить наши текущие наборы возможностей
Переключение пользователя и группы на 'имя_пользователя_вашей_службы'
Добавление возможности cap_net_bind_service к унаследованному и внешнему наборам
Разветвление bash -c 'ваша-команда' (поскольку capsh автоматически запускает bash с аргументами после -- )

Здесь многое происходит под капотом.

Во-первых, мы работаем от имени пользователя root, поэтому по умолчанию мы получаем полный набор возможностей. Сюда входит возможность переключения uid и gid с помощью системных вызовов setuid и setgid. Однако, обычно, когда программа делает это, она теряет свой набор возможностей - это так, что старый способ удаления root с setuid все еще работает. Флаг --keep=1 указывает capsh выполнить системный вызов prctl(PR_SET_KEEPCAPS), который отключает удаление возможностей при смене пользователя. Фактическая смена пользователей с помощью capsh происходит с помощью флага --user, который запускает setuid и setgid .

Следующая проблема, которую нам нужно решить, — это как установить возможности таким образом, чтобы они продолжали действовать после того, как мы выполним наши дочерние элементы. Система возможностей всегда имела «унаследованный» набор возможностей, который представляет собой «набор возможностей, сохраняемых в execve(2)» [capabilities(7)]. Хотя это звучит так, как будто это решает нашу проблему (просто установите для возможности cap_net_bind_service значение inherited, верно?), на самом деле это применимо только к привилегированным процессам, а наш процесс больше не является привилегированным, потому что мы уже сменили пользователя (с флагом --user) .

Новый набор внешних возможностей решает эту проблему — это «набор возможностей, которые сохраняются в execve(2) непривилегированной программы». Поместив cap_net_bind_service во внешний набор, когда capsh exec будет нашей серверной программой, наша программа унаследует эту возможность и сможет привязывать слушателей к младшим портам.

Если вам интересно узнать больше, это подробно описано на странице руководства по возможностям. Прогон капша через strace тоже очень информативен!

Как и многие сетевые демоны, сервер каталогов Sun Java System имеет возможность setuid, которая позволяет запускать его от имени пользователя root, но затем отказываться от привилегий для запуска от имени пользователя с меньшими возможностями. Сервер каталогов OpenDS в настоящее время не включает эту возможность (и для ее реализации потребуется собственный код, что нежелательно). Однако вы можете установить, запустить и запустить сервер каталогов как пользователь без полномочий root. Обратите внимание, что информация в этом разделе относится в первую очередь к платформам на базе UNIX, поскольку исторически системы Windows не накладывали столько ограничений на пользователей без прав администратора.

Причины запуска сервера от имени пользователя без полномочий root

Во многих случаях запуск сервера каталогов от имени пользователя без полномочий root с самого начала является более привлекательным вариантом и обеспечивает большую функциональность, чем эквивалент setuid. Запуск сервера от имени пользователя без полномочий root означает, что администраторам не требуется root-доступ к системе, что часто желательно с точки зрения эксплуатации. Кроме того, с сервером каталогов в сети можно выполнять больше административных действий, поскольку сервер может выполнять действия, которые могли быть недоступны после того, как он отказался от привилегий root.

Основная причина, по которой серверы каталогов обычно запускаются и/или работают от имени пользователя root, заключается в том, что они могут прослушивать привилегированный порт (а именно, порты от 1 до 1024). Стандартный порт для связи LDAP — порт 389, а стандартный порт для LDAPS — 636. В большинстве систем на базе UNIX только пользователи root могут создавать процессы, прослушивающие эти порты. Могут быть и другие причины для запуска в качестве пользователя root (например, возможность использовать большее количество файловых дескрипторов), но, как правило, проще обойти эти другие ограничения.

Несмотря на то, что стандартными портами LDAP и LDAPS являются 389 и 636, сервер каталогов не обязательно должен работать на этих портах. В некоторых средах сервер каталогов обычно запускают на портах выше 1024 (например, 1389 и 1636), поэтому для его запуска не обязательно быть пользователем root. Практически все клиенты с поддержкой LDAP предоставляют возможность указать порт, который прослушивает сервер. Пока клиенты знают, какой порт использует сервер, разрешено любое значение. Сведения о настройке порта прослушивания см. в разделе Настройка обработчика соединений LDAP.

Как работать от имени пользователя без полномочий root на стандартных портах LDAP

Если клиенты ожидают, что сервер будет прослушивать порт 389 или 636, по-прежнему доступны другие варианты. Лучшим вариантом, доступным в Solaris 10, является использование подсистемы управления правами процессов (также называемой минимальными привилегиями). Подсистема привилегий в Solaris позволяет предоставлять обычным пользователям и ролям возможности, которые обычно доступны только пользователю root (во многом так же, как позволяет подсистема привилегий на сервере каталогов). В частности, привилегия net_privaddr определяет, какие пользователи могут привязываться к привилегированным портам. Если эта привилегия предоставлена пользователю без полномочий root, этот пользователь может привязываться к привилегированным портам. Чтобы настроить пользователя с этой привилегией, выполните следующую команду от имени пользователя root:

Эта команда настраивает пользователя opens таким образом, чтобы он начинал с базового набора привилегий (который по умолчанию есть у пользователей без полномочий root). Затем команда добавляет привилегии net_privaddr и sys_resource, которые, среди прочего, позволяют пользователю увеличить количество доступных файловых дескрипторов. Команда удаляет привилегию proc_info (которая позволяет пользователю видеть процессы, принадлежащие другим пользователям) и привилегию file_link_any (которая позволяет пользователю создавать жесткие ссылки на файлы, которые он не владею). После запуска этой команды пользователь opends может запустить сервер каталогов, прослушивающий привилегированный порт.

Даже в системах без такой возможности, как наименьшие привилегии, можно открыть сервер каталогов на привилегированном порту, таком как 389 или 636, не требуя привилегий root для его запуска. Одной из возможностей может быть запуск сервера на непривилегированном порту и использование прокси-сервера каталога, прослушивающего привилегированный порт, для перенаправления связи на сервер каталога через непривилегированный порт. Также можно использовать сетевое оборудование для достижения той же цели или использовать правила брандмауэра в той же системе. Например, в системах Linux можно использовать следующие команды для перенаправления трафика с порта 389 на порт 1389:

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