ldap authentication + time restriction

вообще-то это авторизация, а не аутентификация

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

ну существует pam_time, в принципе ничего не мешает генерить его конфиг из ldap. как прибивать... я бы проверял /var/log/wtmp и тех кто не подходит убивал.

Как я и предполагал - напильник средних размеров ;/

> Как объяснить в pam/ldap, что пользователю Васе можно логиниться с 12 до 12.30?

Никак. Использовать модуль pam_time.

> Доп. вопрос - как сделать так, чтоб залогиненного Васю выкидывало в
> 12.30 изо всех его сессий?

Со стандартным ядром, AFAIK, только

kill -9 `ps h -o pid -U pupkin`

> Никак. Использовать модуль pam_time.

Беда в том, что он к ldap не привязан. Напильник #1.

> kill -9 `ps h -o pid -U pupkin`

Ага. Так и придется - хотя это криво, на самом деле. Ну, сначала просто kill, без -9, но это не суть. Напильник #2.

> > Никак. Использовать модуль pam_time.
> Беда в том, что он к ldap не привязан. Напильник #1.

Угу... Начинаем пинать разработчиков? :)

> > kill -9 `ps h -o pid -U pupkin`

> Ага. Так и придется - хотя это криво, на самом деле.

Согласен что криво, но как ровно-то? Чтоб вместо UID/GID был TGT?

Про pam_ldap я еще понимаю, как нужно: чтоб он не только auth-модулем
был, но еще и account и session (чтоб в LDAP можно было держать ограничения
по времени, переменные окружения, etc.)

Но вот что делать с запущенными процессами и открытыми файловыми
дескрипторами?

> Но вот что делать с запущенными процессами и открытыми файловыми дескрипторами?

Боюсь, что решение может быть только на уровне конкретного десктопа. Например, перед смертью послать всем прикладухам пользователя по dbus сообщение (или даже парочку) "сейчас вас будут немножко убиффат" - и дать несколько секунд-минут на корректное завершение. А потом уж и kill и kill -9 - тем, кто остался.

Попинать разработчиков pam_ldap - это, пожалуй, мысля...

> > Но вот что делать с запущенными процессами и открытыми файловыми
> > дескрипторами?

> Боюсь, что решение может быть только на уровне конкретного десктопа.

Не, это desktop не должен отвечать за безопасность (да и не может он
этого сделать). Но я не то имел в виду. В *NIX пользователь проходит
аутентификацию один раз и "навечно": запущенный процесс может болтаться
сколько угодно пока его кто-то не прибьет, открытый однажды файл можно
пользовать хоть до второго пришествия. Права доступа на файлы определяют,
кому и что можно с ними делать, но совершенно не ограничивают _когда_
это можно делать. rlimits не накладывают почти никаких ограничений
по времени (кроме практически бесполезного ограничения на CPU time).
Интересно -- это просто исторически так сложилось или за этим стоит
какой-то глубокий смысл?

Попытки подхакать ядро на предмет такого рода ограничений уже были.
В NFSv4 и AFS права доступа -- это не UID/GID => допустимые операции,
а Kerberos credentials (которые рано или поздно устаревают) => допустимые
операции. Патч RSBAC (http://www.rsbac.org) позволяет явно задавать время
действия прав доступа. Но далеко не всему *NIX'овму софту нравится такая
семантика (cron, postfix), да и юзвери тоже не в восторге (хотя кто
у них спрашивать будет :P)...

> Не, это desktop не должен отвечать за безопасность (да и не может он этого сделать).

Разумеется, подразумевалось "в условиях, когда нет целостной политики на уровне ядра". Разумеется, решение на уровне ядра (с нотификациями, засылаемыми вверх по стеку) - намного правильнее.