[LEDE-DEV] convention on uid/gid for packages

[Val Kulkov]

On 15 May 2017 at 09:46, Yousong Zhou <yszhou4tech at gmail.com> wrote:
> On 15 May 2017 at 21:07, Val Kulkov <val.kulkov at gmail.com> wrote:
>> On 15 May 2017 at 02:30, Alexandru Ardelean <ardeleanalex at gmail.com> wrote:
>>> On Sun, May 14, 2017 at 3:59 AM, Daniel Golle <daniel at makrotopia.org> wrote:
>>>> Hi Val,
>>>>
>>>> On Sat, May 13, 2017 at 06:23:29PM -0400, Val Kulkov wrote:
>>>>> Is there any convention on the use of uid and gid when creating new
>>>>> users or groups? Can someone point me to it, if it exists?
>>>>>
>>>>> I noticed that two packages, icecast and postfix, compete for the same uid=87:
>>>>>
>>>>> icecast's Makefile:
>>>>>   USERID:=icecast=87:icecast=87
>>>>>
>>>>> postfix's postfix.init:
>>>>>   user_exists postfix || user_add postfix 87
>>>>
>>>> This looks wrong to me (user_add in the init script)...
>>>>
>>>>>
>>>>> There may be more packages competing for the same uid/gid's, I have
>>>>> not fully researched it.
>>>>>
>>>>> I am preparing a new package, opendkim, which should be run as a
>>>>> non-privileged user. For this,
>>>>> USERID:=opendkim=<something>:opendkim=<something> seems appropriate,
>>>>> but what numbers should I assign?
>>>>
>>>> I run into this issue before and believe that we should have a wiki
>>>> page which allows registering static UIDs/GIDs at least for the
>>>> packages which actually need that (ie. if a specific UID or GID is
>>>> referenced in other packages, or scripts like firewall rules, ...).
>>>> Grep'ing for USERID allows to automatically generate that list based
>>>> on the currently available packages very easily.
>>>>
>>>> Examples from elsewhere for inspiration:
>>>>
>>>> FreeBSD got those lists
>>>> https://svnweb.freebsd.org/ports/head/UIDs?view=markup
>>>> https://svnweb.freebsd.org/ports/head/GIDs?view=markup
>>>>
>>>> linuxfromscratch got a much smaller list for essential/system UIDs/GIDs
>>>> http://linuxfromscratch.org/blfs/view/svn/postlfs/users.html
>>>>
>>>>
>>>> Cheers
>>>>
>>>
>>> Just woke up from the weekend.
>>> I recommend trying this out [based on lldpd] :
>>> https://github.com/lede-project/source/blob/master/package/network/services/lldpd/Makefile#L35
>>> We use lldpd and this seems to work ; lldpd does some priv separation.
>>>
>>> Alex
>>
>> Alexandru, the USERID:= construct works really well, but my question
>> was about the convention to avoid conflicts while picking numbers for
>> new UID and GID. For example, icecast and postfix both use 87 for a
>> new UID they create.
>>
>> I think the links to FreeBSD's UID and GID lists that Daniel provided
>> are indeed an excellent source of inspiration. We should a Wiki page
>> with a similar content.
>>
>
> If it's only about allocation of uid/gid without collision, then the
> default_postinst() func will just do that [1], e.g.
> USERID:=icecast:icecast
>
> I do not know of any service checking non-root username of its
> effective uid/gid and quit if they fail expectation.  The other thing
> is that if we allow auto-allocation with default_postinst and preserve
> /etc/{passwd,group} across sysupgrade, then the global allocation of
> uid/gid may not work out because those slots may already be taken up
> by the auto-allocation happen prior of time...
>
>  [1] https://github.com/openwrt/packages/pull/3150#discussion_r83354888

The auto-allocation of uid/gid emulates useradd/groupadd, picking the
first unused uid/gid starting from 100. This works quite well on its
own, but there are about three dozen packages in the packages repo
that come with hardcoded uid/gid's:

find -L package/ -name Makefile -exec grep 'USERID:=' {} \;

produces 35 or so lines indicating the assignment of hardcoded uids and gids.

At present, if someone installs five packages that use the
auto-allocation mechanism, uids 100-105 will be taken by the
auto-allocation mechanism (101 is already taken by 'network'). After
that, attempting to install the 'avahi' package will result in a
conflict:
   USERID:=avahi=105:avahi=105

IMO such conflicts can and must be avoided. Perhaps the easiest way to
avoid such conflicts is to maintain a list of uid/gid allocation (a la
FreeBSD) and have a policy in place regarding the allocation of new
uid/gid's. For example, the 1-999 range may be reserved for services
and starting from 1000 for regular users. IMO this is an important
step forward in creating a resilient package space environment.