pam.d directory 0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/opt/taram/param/application

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

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

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

/opt/taram/param/application

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

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

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

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

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

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

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

session  required   pam_limits.so

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

root    nofile     5

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

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

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

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

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

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

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

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 стоит?

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

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