nixp.ru v3.0

18 октября 2017,
среда,
14:28:29 MSK

DevOps с компанией «Флант»
Vourhey написал 3 июня 2008 года в 15:57 (608 просмотров) Ведет себя как мужчина; открыл 4 темы в форуме, оставил 13 комментариев на сайте.

Есть такая директория /etc/pam.d В ней лежат конфиги с именем соответствующей команды. Имеется ли возможность прописать конфиг не к команде, а к своему приложению, путей к которому нет в $PATH? Если да, то каким образом можно это сделать?

Дело в том, что приложение должно вызываться через запуск стороннего скрипта. То есть, без прямого доступа к самому приложению. А ограничения /etc/security/limits.conf надо к его запуску применить. Есть ли еще какое-нибудь решение?

Dr. Evil

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

Два варианта решения задачи:

1. Прописать в $PATH пользователя путь до не существующего каталога с исполняемыми файлами.

2. В домашнем каталоге пользователя bin/ (~/bin/) создать файл командой:

ln -s /путь_до_нужного_исполняемого_файла ~/bin/_имя_нужного_исполняемого_файла_на_который_делаем_ссылку

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

Vourhey

Спасибо. Да, Вы верно поняли вопрос.

Только, юзер, после создания ссылки сможет сам ручками запустить приложение, так как, ссылка в бине лежит. Но он должен работать через «оболочку» из скриптов.

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

fly4life
Vourhey
Есть такая директория /etc/pam.d В ней лежат конфиги с именем соответствующей команды. Имеется ли возможность прописать конфиг не к команде, а к своему приложению, путей к которому нет в $PATH? Если да, то каким образом можно это сделать?

Дело в том, что приложение должно вызываться через запуск стороннего скрипта. То есть, без прямого доступа к самому приложению. А ограничения /etc/security/limits.conf надо к его запуску применить. Есть ли еще какое-нибудь решение?

В /etc/pam.d лежат сценарии аутентификации для приложений. Причём называются сценарии, как правило, тем же именем, что и приложение (а не именем команды, которой приложение вызывается, как ты подумал). Для того, чтобы «прописать конфиг к своему приложению» (т.е. составить сценарий аутентификации), это твоё приложение должно уметь работать с PAM. Пути к приложению вообще ни при чём.

Vourhey

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

Хм…я могу прописать в ~/bin/blabla любую апликуху потом сделать в pam.d по имени blabla конфиг и он применится. Вот и команда. Если не напишу, то limits.conf не повлияет на него.

(Не ну забавно так «конфигурационный файл» и «сценарий» делает огромную разницу в данном контексте. В данном случае, и сценарий и конфиг, оба вполне применимые слова. Так как, это конфигурационный файл, описывающий сценарий)

fly4life
Vourhey
Это все понятно. Вопрос в том, как задать нужный сценарий для этого приложения.

Хм…я могу прописать в ~/bin/blabla любую апликуху потом сделать в pam.d по имени blabla конфиг и он применится. Вот и команда. Если не напишу, то limits.conf не повлияет на него.

(Не ну забавно так «конфигурационный файл» и «сценарий» делает огромную разницу в данном контексте. В данном случае, и сценарий и конфиг, оба вполне применимые слова. Так как, это конфигурационный файл, описывающий сценарий)

Я тогда не понял суть поставленной задачи. У тебя не исполняется сценарий PAM для приложения, путь до бинарника которого отсутствует в $PATH?

Vourhey

Сори, за запутанные объяснения.

Я не могу понять, как сопоставить конфигурационный файл с приложением, не применяя таких методов, как описал Dr. Evil.

То есть. К примеру, у меня есть исполняемый файл:

/opt/taram/param/application

Конечно, поместить в pam.d файл application не получится (вернее получится, но бестолку).

Но, если мы создадим в bin символьную ссылку на /opt/taram/param/application и обзовем ее «application», то создание файла с именем «application» в pam.d будет оправданным. Но тогда юзер сможет спокойно набрать в консоли application и запустить прогу, как ему вздумается, что не есть хорошо.

fly4life
Vourhey
То есть. К примеру у меня есть исполняемый файл:

/opt/taram/param/application

Конечно, поместить в pam.d файл application не получится (вернее получится, но бестолку).

Вот с этого места поподробнее =). Почему бестолку?

Vourhey

:) Ну потому что, этот сценарий не применяется к /opt/taram/param/application

Или надо, все-таки, спать по ночам…

Vourhey

Хех. Можно немного сменить вопрос? :)

К примеру, я имею обычный самый такой демон crond. Чтобы задать ему лимит на количество открытых файлов надо:

1. написать в /etc/pam.d/crond строчку

session  required   pam_limits.so

2. и в limits.conf задать, к примеру:

root    nofile     5

Что изменить, чтобы это заработало?

Нет, все в порядке. Сейчас попробовал на Mandriva там все ок. А вот на RedHat, почему-то вообще ноль реакции на изменение в limits.conf. После «root nofile 5» в мандрива вообще не залогинишься под рутом, что логично, в принципе. а вот рэдхату хоть бы хны :(

fly4life
Vourhey
:) Ну потому что, этот сценарий не применяется к /opt/taram/param/application

Или надо, все-таки, спать по ночам…

Ага, я тоже клоню к тому, что всё-таки применяется ;).

Есть предположение, что беда именно в редхатовском cron, который игнорирует limits.conf (кстати, какой redhat?).

Vourhey

Enterprise вроде 2.6.9. Да вообще, прикол еще в том, что даже не то, что crond там чего-то. Как вообще под рутом можно логиниться, когда ограничение открытых файлов в 5 стоит?! Мандрива сразу логин отрубает с фразой «Can not open session» (стоит только одну строчку добавить в limits.conf). Не могу понять, почему так… В PAM проблема? И еще забрался вопрос в голову: lsmod должен показывать, что PAM стоит? Хотя, странно, так как, к примеру, pam_rootok.so работает…

fly4life
Vourhey
Enterprise вроде 2.6.9. Да вообще, прикол еще в том, что даже не то, что crond там чего-то. Как вообще под рутом можно логиниться, когда ограничение открытых файлов в 5 стоит?! Мандрива сразу логин отрубает с фразой «Can not open session» (стоит только одну строчку добавить в limits.conf). Не могу понять, почему так… В PAM проблема?

Либо у тебя нет указания на использование pam_limits в /etc/pam.d/login, либо некорректно задана строчка в limits.conf. Например, отсутствует указание типа лимита (hard или soft).

Vourhey
И еще забрался вопрос в голову: lsmod должен показывать, что PAM стоит?

Нет, не должен.

Vourhey

РАМ стал подавать признаки жизни на RHEL5 только…