Re: [devel] libnss_role

Re: [devel] libnss_role

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Fri, Nov 14, 2008 at 07:53:30PM +0300, Dmitriy M. Maslennikov wrote:
[...]
> С помощью NSS модуля, разработанного нами, можно решить эту проблему
> более красивым способом. Модуль находится по адресу
> http://www.tartarus.ru/wiki/Projects/libnss_role и позволяет добавлять
> группу в группы.

Читаю обоснование выбора формата конфигурации, приведённое в
http://www.tartarus.ru/wiki/Projects/libnss_role/administration
и думаю о том, что у groupmod(8) есть не только ключ -n, но и ключ -g.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] libnss_role

[Dmitriy M. Maslennikov]

16 ноября 2008 г. 21:18 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> Читаю обоснование выбора формата конфигурации, приведённое в
> http://www.tartarus.ru/wiki/Projects/libnss_role/administration
> и думаю о том, что у groupmod(8) есть не только ключ -n, но и ключ -g.
При смене идентификаторов "портятся" права на файловой системе
(объекты файловой системы начинаю либо никому не принадлежать, либо
принадлежать случайной группе). Поэтому смена идентификатора гораздо
более опасная операция. Поэтому мы взяли за основу идентификаторы. На
ЛОРе нам показали случаи, когда имена все-таки необходимы. Мне кажется
единственный вариант - поддержать в файле конфигурации и то, и то.
Опытный администратор выберет. А вот утилиты, по-моему, лучше пусть
основываются по-прежнему на идентификаторах.

У кого нибудь еще есть соображения по этому поводу?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] libnss_role

[Led]

On Sunday, 16 November 2008 21:42:49 Dmitriy M. Maslennikov wrote:
> 16 ноября 2008 г. 21:18 пользователь Dmitry V. Levin <ldv@altlinux.org> 
написал:
> > Читаю обоснование выбора формата конфигурации, приведённое в
> > http://www.tartarus.ru/wiki/Projects/libnss_role/administration
> > и думаю о том, что у groupmod(8) есть не только ключ -n, но и ключ -g.
>
> При смене идентификаторов "портятся" права на файловой системе
> (объекты файловой системы начинаю либо никому не принадлежать, либо
> принадлежать случайной группе). Поэтому смена идентификатора гораздо
> более опасная операция. Поэтому мы взяли за основу идентификаторы. На
> ЛОРе нам показали случаи, когда имена все-таки необходимы. Мне кажется
> единственный вариант - поддержать в файле конфигурации и то, и то.
> Опытный администратор выберет. А вот утилиты, по-моему, лучше пусть
> основываются по-прежнему на идентификаторах.
>
> У кого нибудь еще есть соображения по этому поводу?

Есть. Как я ни смотрел (и вдоль, и поперёк) - так и не увидел зачем там нужен 
nss-модуль. Мне кажется, что неколько утилит могли бы поддерживать этот 
ролевой уровень абстракции (с периодическим или по крону синком /etc/group 
и /etc/role

-- 
Led

Re: [devel] libnss_role

[Dmitriy M. Maslennikov]

16 ноября 2008 г. 22:58 пользователь Led <ledest@gmail.com> написал:
> Есть. Как я ни смотрел (и вдоль, и поперёк) - так и не увидел зачем там нужен
> nss-модуль. Мне кажется, что неколько утилит могли бы поддерживать этот
> ролевой уровень абстракции (с периодическим или по крону синком /etc/group
> и /etc/role
По-моему, задача этого модуля как раз упразнить эти "несколько утилит
и синк по крону".

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] libnss_role

[Led]

On Sunday, 16 November 2008 22:06:40 Dmitriy M. Maslennikov wrote:
> 16 ноября 2008 г. 22:58 пользователь Led <ledest@gmail.com> написал:
> > Есть. Как я ни смотрел (и вдоль, и поперёк) - так и не увидел зачем там
> > нужен nss-модуль. Мне кажется, что неколько утилит могли бы поддерживать
> > этот ролевой уровень абстракции (с периодическим или по крону синком
> > /etc/group и /etc/role
>
> По-моему, задача этого модуля как раз упразнить эти "несколько утилит
> и синк по крону".

Она решает задачу синхронизации /etc/role с /etc/group, если в последнем 
произршли изменения?

-- 
Led

Re: [devel] libnss_role

[Evgeny Sinelnikov]

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



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] libnss_role

[Led]

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

Ну, тогда зачем nss-модуль, если всё равно - "вручную"?

-- 
Led

Re: [devel] libnss_role

[Evgeny Sinelnikov]

16 ноября 2008 г. 23:49 пользователь Led <ledest@gmail.com> написал:
> On Sunday, 16 November 2008 22:45:17 Evgeny Sinelnikov wrote:
>> 16 ноября 2008 г. 23:26 пользователь Led <ledest@gmail.com> написал:
>> > On Sunday, 16 November 2008 22:06:40 Dmitriy M. Maslennikov wrote:
>> >> 16 ноября 2008 г. 22:58 пользователь Led <ledest@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)