[devel] libnss_role

[Evgeny Sinelnikov]

16 ноября 2008 г. 23:49 пользователь Led <ledest at gmail.com> написал:
> On Sunday, 16 November 2008 22:45:17 Evgeny Sinelnikov wrote:
>> 16 ноября 2008 г. 23:26 пользователь Led <ledest at gmail.com> написал:
>> > On Sunday, 16 November 2008 22:06:40 Dmitriy M. Maslennikov wrote:
>> >> 16 ноября 2008 г. 22:58 пользователь Led <ledest at gmail.com> написал:
>> >> > Есть. Как я ни смотрел (и вдоль, и поперёк) - так и не увидел зачем
>> >> > там нужен nss-модуль. Мне кажется, что неколько утилит могли бы
>> >> > поддерживать этот ролевой уровень абстракции (с периодическим или по
>> >> > крону синком /etc/group и /etc/role
>> >>
>> >> По-моему, задача этого модуля как раз упразнить эти "несколько утилит
>> >> и синк по крону".
>> >
>> > Она решает задачу синхронизации /etc/role с /etc/group, если в последнем
>> > произршли изменения?
>>
>> Предполагается, что локальные идентификаторы обычно не меняются, иначе
>> придётся пробегать по всей файловой системе и изменять их вручную, в
>> этом случае можно и в /etc/role их изменить... Я подумаю как бы то
>> сделать с помощью утилиты, но в общем-то пока не вижу иного выхода,
>> чем вручную, впрочем как и для файловой системы...
>
> Ну, тогда зачем nss-модуль, если всё равно - "вручную"?
>

Я, конечно, пишу длинные письма, но обоснование я давал... :)

http://lists.altlinux.org/pipermail/devel/2008-November/163025.html

Модуль нужен чтобы сформировать так называемые nested groups, для
реализации локальной политики рабочей станции.
Преимущества у этого подхода два:

1. Локальное преимущество:
1.1. не нужно пробивать в утилитах настройки списки групп - достаточно
одной или нескольких групп-ролей.
1.2. легко добавить всех пользователей выбранной категории (роли) во
все нужные группы, не забыв никого
1.3. легко удалить всех нужных пользователей выбранной категории
(роли), не забыв никого (хотят тут есть вопрос об исключениях)
1.4. легко создать новую категорию (роль) пользователей и перемещать
пользователей из категории в категроию. При этом права категорий
(ролей) назначаются отдельно, поэтому легко ими оперировать...
1.5. появляется возможность задать политику по умолчанию, вносящую
привилегии от устанавливаемых приложений в заданные категории (admins,
power, users)

2. Глобальное преимущество:
2.1. Появляется возможность отделить локальную политику от глобальных
объектов. То есть не переносить необходимость хранения этих локальных
настроек на сервер, привязываясь к нему.
2.2. При этом, получается гибкий инструмент для предоставления
локальных привилегий глобальным группам путём включения этих
глобальных групп в локальные роли. То есть достаточно на любом
компьютере в сети внести группу global_users в группу users и члены
global_users получат все привилегии, что и локальные пользователи.
Причём, не заданные на сервере, а такие какие были настроены на этой
рабочей станции.


-- 
Sin (Sinelnikov Evgeny)