[devel] Re: [POLICY] uid/gid creation (was: [sisyphus] tftp...)

Michael Shigorin =?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Пт Янв 16 15:36:04 MSK 2004


2 devel: кажется, набросалась альфа политики по добавлению
псевдопользователей.

Требуются комментарии ldv@, в первую очередь.

On Fri, Jan 16, 2004 at 03:03:51PM +0400, Sergey wrote:
> Вообще, в спеке, который я за основу взял (PLD Linux), использован 
> такой вот вариант (недоработан по поводу GID почему-то...):

Да, у меня в sympa.spec в итоге тоже так сделано (вспомнил!).
Он происходит, кажется, от Mdk'шного с mixin'ами других.

> %pre -n utftpd
> if [ -n "`id -u tftp 2>/dev/null`" ]; then
>         if [ "`id -u tftp`" != "114" ]; then
>                 echo "Error: user tftp doesn't have uid=114. Correct this before installing utftpd." 1>&2
>                 exit 1
>         fi
> else
>         echo "Adding user tftp UID=114."
>         /usr/sbin/useradd -u 114 -r -d /dev/null -s /dev/null -c "TFTP User" -g tftp tftp 1>&2
> fi
> 
> В таком случае оно тоже не цепляется за другие пакеты особо... 

...но, с другой стороны, при этом повышается скрытая
чувствительность к беспределу в виде просто useradd -r (в т.ч. из
уже установленных альтовских пакетов, которые так делают).

> Что касается локального системного администратора... Это, как
> раз, наоборот хорошо, как мне кажется, когда есть возможность
> переставить систему и вернуть только пользовательские
> настройки, рассчитывая, что ID не поменяются, вне зависимости
> от порядка доустановки пакетов.

Так о чем и речь.

> > Сергей, эта тема уже обсуждалась -- если возьметесь написать
> > предложение по пресловутой политике, ура. 
> Да я тут наобещал уже список Intel Etherexpress PRO, которые с
> e100 работают, да ifup по поводу VLAN посмотреть. Пока опасаюсь
> еще что-то обещать... :-)

Ну так TODO и вычеркивать :-)  Помогает.

Можете на http://www.linux-os.ru/forums/arrangements/ забросить
для себя и других на напоминание и выявление общих интересов.

(2 avl: кстати про общие интересы: не хочешь сделать
cards.atmsk.ru или cards.linux-os.ru на базе cards.sf.net?)

> Могу только предложить вести публично (или в пакете
> соответствующем) некий список UID/GID

Да, в таком случае это понадобится, но будет скорее таким себе
RFC, а не жесткой технологической зависимостью.

Причем _проверять_ получится: списки в /usr/lib/rpm/ и завернуть
процедуру добавления в компактный макрос -- тогда значения,
которые ему передаются (имя/номер пользователя/группы) можно
будет проверять на уникальность по референсному списку.

Честно говоря, хотелось бы при этом минимизировать namespace
clash с обычными пользовательскими аккаунтами каким-то
префиксом/суффиксом: ведь пользовательские аккаунты вида "lp@"
или "rpc@" (по инициалам) вполне можно себе представить, а
проблема будет потихоньку заостряться с углублением privilege
separation, особенно если майнтейнеры будут занимать короткие
имена/акронимы.

(если копнуть -- то здесь проблема с тем, что и люди, и проекты
обычно стремятся иметь id в разумно краткой, уникальной и
запоминающейся форме; а в /etc/passwd пользователи,
представляющие людей, и псевдопользователи, представляющие
проекты, как раз и пересекаются)

> и, возможно, в useradd/groupadd проверку с предупреждением
> вставить по поводу использования значений в предопределенной
> области.  

Так -r?

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20040116/65defe68/attachment-0001.bin>


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