Никаких LoggedOn. В любого юзера, только при наличии соответствующей capability (в норме она есть только у рута), и главное, это билет в один конец.
И это правильно, потому что если позволить прыгать туда-сюда, то в адресном пространстве накопятся данные, полученные от имени разных пользователей (включая, например, логин-пароль), и это похерит всю безопасность, за которую сражался Ку.
Поэтому практика применения setuid() включает выполнение минимум одного exec() на каждый setuid() - либо незадолго до, либо сразу после.
login, sudo и su работают по схеме "сразу после" - авторизовали юзера, setuid() и сразу exec() команды, которая уже будет выполняться от юзера. При этом в памяти процесса гарантированно не будет данных, которые были в памяти родителя-рута, и которые юзеру знать не положено.
А всякие почтовки, веб-сервера и т.п., особенно когда надо SSL, предусматривают возможность некоторые данные прочесть под рутом и сохранить после setuid() - у них, соответственно, exec(), минимальная инициализация под рутом, setuid(), и только потом остальная инициализация.
no subject
И это правильно, потому что если позволить прыгать туда-сюда, то в адресном пространстве накопятся данные, полученные от имени разных пользователей (включая, например, логин-пароль), и это похерит всю безопасность, за которую сражался Ку.
Поэтому практика применения setuid() включает выполнение минимум одного exec() на каждый setuid() - либо незадолго до, либо сразу после.
login, sudo и su работают по схеме "сразу после" - авторизовали юзера, setuid() и сразу exec() команды, которая уже будет выполняться от юзера. При этом в памяти процесса гарантированно не будет данных, которые были в памяти родителя-рута, и которые юзеру знать не положено.
А всякие почтовки, веб-сервера и т.п., особенно когда надо SSL, предусматривают возможность некоторые данные прочесть под рутом и сохранить после setuid() - у них, соответственно, exec(), минимальная инициализация под рутом, setuid(), и только потом остальная инициализация.