Stanislav Maslovski пишет:
> On Fri, Aug 21, 2009 at 02:15:26AM +0800, Денис wrote:
>> Stanislav Maslovski пишет:
>>> On Fri, Aug 21, 2009 at 01:11:44AM +0800, Денис wrote:
>>>> Stanislav Maslovski пишет:
>>>>> On Fri, Aug 21, 2009 at 12:28:43AM +0800, Денис wrote:
>>>>>> Можно ли корректно создать группу без названия? только с gid?
>>>>> Сначала четко сформулируй, зачем тебе это надо.
>>>> надо? эту группу никто, кроме самого скрипта использовать не будет,
>>>> соответственно и имя благозвучное задавать ей не надо и генерироваться
>>>> оно будет автоматом. Вот, хочу узнать можно ли обойтись вообще без имени
>>>>
>>>>> Унутрях система
>>>>> использует численные UID и GID, так что в принципе всё можно.
>>>> угу, я в курсе
>>>>
>>>> "корректно" - значит если вдруг система перейдёт на хранение
>>>> имен-паролей не в файловых db а в ммм эээ в NIS, то чтобы ничего не
>>>> сломалось в моём скрипте
>>> Постановка задачи корректнее некуда ;) "чтобы ничего не поломалось".
>>>
>> ...в случае смены используемой базы данных паролей.
>>
>>> С точки зрения ядра, UID, GID, EUID, EGID и список supplementary GIDs
>>> - это всё свойства процесса, наследуемые через fork() and exec() (c
>>> некоторыми деталями, которые мы опустим).
>>>
>>> chown(2), chmod(2) работают безотносительно /etc/{passwd,group} или
>>> любой другой базы аутентификации. Проверки доступа к файлам и
>>> каталогам - аналогично. Поэтому, если ты сумеешь организовать вызов
>>> своего скрипта в нужном контексте, у тебя "ничего не поломается."
>>>
>> Ну да, верно.
>
> Вот спасибо-то ;)
>
>> Я не о обработке пользователей ядром а о том, как правильно создавать
>> группу системными скриптами.
>
> По-моему, ты зациклился на том, что группы надо _создавать_, а я тебе
> пытаюсь обяснить, что их (GIDs) можно использовать безотносительно
> создания записей в любых базах.
Не получится их просто так на ровном месте использовать - придётся всё
равно поддерживать базу уже используемых. Так что пускай это и будет
системная база.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
