[python] как демону запущенному из под root рабоать от имени обычного пользователя?

Можно 1) заюзать аналог inetd, он всё сделает сам или б) понижать права демона сразу после старта как в любом другом юниксовом демоне.

Можно 1) заюзать аналог inetd, он всё сделает сам или б) понижать права демона сразу после старта как в любом другом юниксовом демоне.

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

Лично мне видится два варианта:

• Оставить права как есть, то есть демон будет всегда работать от root'а. А при работе для каждого пользователя «вручную» (то есть не средствами ОС) проверять права. Минусы:
  • Не безопасно.
  • Придётся учитывать всякие тонкости, вроде наличия POSIX ACL / NFSv4 ACL. А это сложно.
• Мастер-процесс, обслуживающий подключения, для каждого пользователя будет форкаться и сбрасывать права. Примерно так работает smbd. Минус: может быть сложно реализовать в рамках существующей архитектуры демона.

Да, только процесс лучше не форкать - есть данные (большие), которые являются общими для всех нитей демона.

Да, только процесс лучше не форкать - есть данные (большие), которые являются общими для всех нитей демона.

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

Или вообще в какую-либо внешнюю СУБД. Зависит от того, какие именно там данные и какие операции с ними производятся.

Ему нужно сделать примерно как в smbd - на каждого свежеподключившегося пользователя форкается процесс

inetd в любом случае решает вопрос листенера соединений. Далее можно написать прослойку которая будет делать авторизацию на своём протоколе, понижаться до прав нужного пользователя и запускать существующий скрипт.

Да, только процесс лучше не форкать - есть данные (большие), которые являются общими для всех нитей демона.

статические или динамические?

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

Я наивно думал, вдруг на питоне можно для нити (ГЫЫЫ) как то сбросить права?;-))))

Динамические. Это такой ком из записей хитрой СУБД, которую как бы демон и призвать обслуживать... Каждая запись ассоцирована с директорией (расчетом, у которого есть свой хозяин), но они гипотетически могут взаимодействовать.

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

Хм... Посмотри в сторону модуля multiprocessing. Может он тебе поможет. Там вроде были какие-то средства для организации общего доступа к одним и тем же данным из разных процессов.

Я наивно думал, вдруг на питоне можно для нити (ГЫЫЫ) как то сбросить права?;-))))

ИМХО сброс прав для одной нити процесса не имеет смысла с точки зрения безопасности.

Просто ты вообще не понимаешь ничего в линупсе. Вот и думал. Стивенса и вахалию читай до полного просветления

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

> Просто ты вообще не понимаешь ничего в линупсе. Вот и думал. Стивенса и вахалию читай до полного просветления

Не, я подожду пока СИМВОЛ выпустит что нить за Вашим авторством, надо ж первоисточники вечной мудрости читать! Анонимус с ЛОРа <<все о линуПсе и смежных вопросах>>, С-Пб.: 2012, 4096 C.

Звучит то как... очень ждем!

Динамические. Это такой ком из записей хитрой СУБД, которую как бы демон и призвать обслуживать... Каждая запись ассоцирована с директорией (расчетом, у которого есть свой хозяин), но они гипотетически могут взаимодействовать.

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

Ок. Спасибо!

Так нет никаких проблем слушать на порту. Хоть через CAP_NET_BIND_SERVICE, хоть биндиться и сразу права дропать.

есть проблема держать демон который не будет падать и будет перезапускаться когда нужно. Без inetd, или аналога, нужно писать свой мастер процесс, а это ещё одна отдельная задача.

Хотя после уточнений ТС такой подход уже не актуален, нужно держать всегда работающий процесс с общей БД. Т.е. нормальный демон так или иначе писать придётся.

держать демон который не будет падать

Всё в руках программиста :). Перезапуск это жуткий костыль. Т.е. это означает что прогеры не справились со своими багами и поэтому решили что перезапуск решает проблему.

Не, перезапуск нам не нужен;-)

Меня тут проблема авторизации внезапно взволновала - сходу ничего внятного не нашел (теоретически то представляю как оно должно быть, а хочу готовый вариант из коробки ;-)). Есть ли какое нить стандартное, лаконичное и кроссплатформенное (клиенты частично под виндой) решение под питон, что б клиенту сказали логин-пароль и он дальше убедил сервер что типа свои? при этом желательно пароль в открытом виде не гонять.

стандартное не знаю, но нестандартное пишется за 3 минуты. Надо гонять не plain-text пароли а хэши(хоть md5). А чтобы хэши были каждый раз разные(а то перехватят хэш и привет) отсылай salt который будет добавляться к паролю. Или вообще в tls всё оберни если у тебя tcp.

В рамках нити нельзя, в рамках процесса - элементарно, man setresuid

Не, перезапуск нам не нужен;-)

под перезапуском подразумевается перезапуск от неожиданного падения через некоторое кол-во циклов. И просто перезапуск воркеров после определённого цикла обслуживаний. Обычная практика, сразу нормальный демон не напишешь.

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

см. SASL

А данные можно поместить например в разделяемую память.

Разшарить управляемые сборщиком мусора данные. Такое вообще в природе бывает?

Это я примерно знаю;-)

Резюме - переходить на многопользовательский режим пока не буду (это все придется переписывать и до конца непонятно как), заведу отдельного пользователя и демон будет трудится от него. Это снимает проблему с авторизацией - виндовые клиентские машины в изолированной локалке и там авторизация вообще не нужна, ну а под линуксом сначала ssh потом локальный коннект, т.е. все решается анализом IP.

Всем огромное спасибо за обсуждение!