Ну и нафиг оно? Что дает?

Ничего не понял, но одобряю!

почитай про PAM лучше

Текст не читал, но одобряю! ;-)

Мда. К 2012 году точно появится если не собственный дистр ЛОР, то собственная операционка ЛОР. Тулкит вон пилят, вылдродень сделает игру, философ... не знаю, тексты для операционки. Я бы сказал, он еще и обои забористые может зафигачить.

Ну чем не всемукапец?

Зачем?

Реже используется метод изменения привелегий процессов. Только и всего. А так я сам еще не придумал зачем это :) Просто такая возможность существует.

Как ты предлагаешь определять привилегии, с которыми надо запускать логин? Еще один логин запускать чтоль?

> Реже используется метод изменения привелегий процессов.

а то он от частого применения перегреется и взорвется?

2012: одна шестая часть суши впала в абсолютное безумие из-за появления нового дистрибутива Linux. Его пользователи становятся настолько фанатичны, что буквально через несколько дней вступают в Освободительную Армию Уничтожения и догоняют уже бушующий по земле Крестовый Поход Против MS. Движение возглавили три человека, единственная достоверно известная информация про которых - то, что они пользователи ЛОРа. Правда, злые языки поговаривают, что один из них жутко неудачлив с девушками, у другого полное отсуствие вкуса, а третий в прошлом работал ночным водителем автобуса.

> Есть идея, что скажете?

Я бы сказал, что пора завязывать.

login — это для локальных пользователей. Соответственно висит на консолях /dev/tty1--/dev/tty6. То есть если ты приватизируешь консоль /dev/tty1 для пользователя tux2001, консоль /dev/tty2 для пользователя tux2002, ... , /dev/tty6 для пользователя tux2006 — то как предлагаешь логиниться любому другому пользователю включая root?

Для удалённых же пользователей тебе никто не мешает прямо сейчас запустить sshd от имени tux2002, единственно что его придётся повесить на непривелигерованный порт > 1024.

> собственный дистр ЛОР

Так уже было же. BolgenOS называется. Попов сначала тут спросил, а потом сделал :)

Кастую сра... ЛОР дистр на основе Gentoo

может просто настал тот момент, когда нужно идти спать?

Идея головного мозга, как минимум.

Привет, Денис!

да, долго ему ещё икать %)
по сабжу - а профит?
секурность?
типа если вдруг приключится «ой» с login-ом, то потенциальный злыдень получит юзера, а не рута?
только это имхо параноя :)

Толку от этой идеи, имо, нуль. Все уже грамотно придумано до нас.

Мне не нравится применение setuid seteuid внутри процесса. Я этого не понимаю. Я понимаю когда один процусс запусает другой и у них разные привелегии.

Я предлагаю от рута sudo -u user login ttyX. Привелегий user должно хватать для проверки его учетных данных.

Примерно так и предполагаю.
При старте системы например одна консоль для входа рута. Остальные консоли да распределены рутом между пользователями, и сетевой вход тоже.

Это просто идея, плюсы и минусы я и жду от вас. Мне интересно ваше мнеие или бы я не писал.

Вообще, чтобы было понятно что натолкнуло меня на эти размышления.
Впоследнее время я много занимался почтой и рассматривал процесс локальной доставки почты в пользовательский почтовый ящик. Я считаю что прикидываться пользователем для локальной доставки неуместно, т.к. пользователь в этом процессе не принимает участия, т.е. MTA должен иметь доступ к почтовому ящику под своей учеткой. Это реализуемо. Забор почты пользователем происходит пользователем через сервисы pop, imap, shell и тут он действует сам через вход в систему через эти сервисы. Сейчас традиционно вход в систеиу происходит через рута, это так и ладно. Но возникает вопрос а есть ли варианты? А по поводу все придумано до нас - хорошо, но жизнь не стоит на месте, у нас тоже есть свои думы и придумки :).

> Мне не нравится применение setuid seteuid внутри процесса. Я этого не понимаю. Я понимаю когда один процусс запусает другой и у них разные привелегии.

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

один процусс запусает другой и у них разные привелегии

, без использования set[r|e]uid?

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

> Я предлагаю от рута sudo -u user login ttyX.

скажи, судо по твоему не использует seteuid?

Привелегий user должно хватать для проверки его учетных данных.

нет.

Использует, но в предложенной мной схеме реже.
Почему категорично нет? Совдепия?

Наркотики - зло.

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

> Мда. К 2012 году точно появится если не собственный дистр ЛОР, то собственная операционка ЛОР. Тулкит вон пилят, вылдродень сделает игру, философ... не знаю, тексты для операционки. Я бы сказал, он еще и обои забористые может зафигачить.

Ну чем не всемукапец?

Хааа!! Повеселил!!! Реквестую сабж!!!

ну и зачем такое изиопство нужно?

и не совсем понятно вот это: Возможность дальнейших входов в систему пользователь обеспечивает себе сам оставляя в системе login от своего имени.

> Привелегий user должно хватать для проверки его учетных данных.
а вот и нет - почитай выхлоп cat /etc/shadow :)
а открывать его юзеру...

>root запускает login с привелегиями этого пользователя

И зачем? ИМХО, теряешь в секьюрности.

В Slackware
ls -la /etc/shadow
-rw-r----- 1 root shadow 593 2010-06-21 16:19 /etc/shadow
Достаточно прав группы shadow.
Непосредственно пользователю, shadow и его хэши открывать не надо, можно сделать программу посредник со sgid shadow, которая например читает username, passwd и завершается с разным exit code в зависимости от успешности проверки. Тогда рядовой пользователь сможет предоставить сервис другому пользователю и провереить его по системной базе без участия root.

Хорошо, login предоставленный root пользователю не завершается и после выхода пользователя из системы продолжает ожидать подключений. Сейчас это решается init через respawn, т.е. каждый раз перезапускает на консоли цепочку ->getty->login. Или я неправ?

Не понял.

Если речь про автологин без xdm, gdm etc, то у меня в /etc/inittab

id:5:initdefault:

x:5:once:/bin/su твой_логин -l -c «/bin/bash --login -c startx — -nolisten tcp -br -deferglyphs 16 >/dev/null 2>/dev/null»

>можно сделать программу посредник со sgid shadow, которая например читает username, passwd и завершается с разным exit code в зависимости от успешности проверки
велик, который будет толкать другой велик? о_О
зачем?