[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