[Comm] Groups

Denis S. Filimonov =?iso-8859-1?q?den_=CE=C1_academ=2Eorg?=
Сб Июл 5 11:00:51 MSD 2003


On Saturday 05 July 2003 13:28, Shawkat wrote:
> > Технически это, конечно, возможно, хотя и крайне некрасиво,
> > поскольку подразумевает вызов из ядра user-space программ и массу
> > других проблем.
>
> Ничего подобного! Через все это система проходит как минимум один раз
> - при авторизации пользователя. Единственно мне хотелось бы чтобы
> процесс определения прав выполнялся бы не один-единственный раз при
> авторизации (а потом этот результат все время использовался бы ), а
> при каждой необходимости.
>
Нет, при аутентификация все происходит в естественном порядке - из user 
space в kernel (login просит ядро изменить ему uid'ы, группы, и т.п.), 
а если для авторизации потребуется узнать что-либо о пользователе, то 
такая потребность возникнет в ядре и обращаться ему придется к 
user-space программам, ответственным за хранение информации о 
пользователях.

> > Но дело не в этом, а в том кто обладает правами: процесс или
> > пользователь. В текущей реализации это процесс, а Вы предлагаете
> > наделить правами пользователя. Первая схема гораздо более гибкая,
> > поскольку позволяет процессам отказываться от лишних прав, или
> > получать дополнительные.
>
> Вот вот - объясните-те ка мне- как какому-либо процессу добавить прав
> не прерывая его. Например, как довесить права процессу bash
> пользователя на какой-либо файл (через механизм группы, а не через
> права файловой системы).
>
setuid, seteuid, etc. Разумеется _лишних_ привелегий получить нельзя, но 
та же setuid'ная программа может на время работать с правами 
запустившего пользователя, а потом вернуться к привелегированному.

> PS. я не понимаю разницы между процессом и пользователем - ведь
> каждый процесс запущен каким-либо пользователем и обладает его
> правами (за исключением особых случаев - suid/gid/ drop root ), тогда
> как пользователя как такового в системе просто не существует - он
> может быть представлен только как процесс.
Вообще-то у процесса целых 4(!) uid'а, это так, к слову :-)
Разница в том, что пользователь, как и группа, всего лишь один из 
атрибутов процесса, которые используются при авторизации. Есть и 
другие, например, так называемые capabilities. Если для авторизации 
использовать только пользователя и группу получится заведомо менее 
гибкая схема.

-- 
Sincerely,
Denis.


Подробная информация о списке рассылки community