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

[Val Kulkov]

On 15 May 2017 at 11:46, Yousong Zhou <yszhou4tech at gmail.com> wrote:
> On 15 May 2017 at 23:29, Val Kulkov <val.kulkov at gmail.com> wrote:
>> Yousong, perhaps I was not clear. What I am suggesting is to change
>> the auto-allocation to start from 1000 rather than from 100 (1000 is
>> just a suggestion, it could be anything else that is high enough), and
>> to have a convention to allocate the 1-999 range to the services.
>> Then, the allocation of uid/gid for any new package would be subject
>> to review and approval by the reviewers. We would have to maintain a
>> Wiki page listing all uids and gids that have already been taken,
>> FreeBSD-style.
>>
>> This way, we would only have to reallocate uids and gids for packages
>> that are 1000 and higher. The other packages that use uids and gids in
>> the 1-999 range would not be affected, other than the packages that
>> already have a conflict (icecast and postfix, for example).
>>
>
> I guess the the user, group related utility functions are intended for
> use by services only.  Adding users and groups for multi-user
> interactive is just not the use case for  LEDE (this is only personal
> opinion and not in the book).
>
> The suggestion is to let default_postinst to auto-allocation uid/gid
> from 1 or 100, and let useradd/useradd/groupadd/addgroup to start from
> whatever high number.
>
> If we can automate things without separately maintaining a list of any
> kind and manual cooperation across groups of people, we should prefer
> that ;)
>
>                 yousong

I agree that not depending on the manual cooperation across groups of
people would be ideal. However, updating 35+ packages to use the
auto-allocation mechanism is not an easy undertaking. Besides, some of
the packages might actually rely on particular numeric uid/gid's - we
don't know until we run tests with these packages.

Here is another suggestion. make menuconfig might collect all USERID:=
strings from all packages and produce a list of uids and gids that
have been taken so that the auto-allocation mechanism will stay away
from these uids/gids. Such lists will likely be fairly compact, taking
perhaps less than 500 bytes. This will (1) avoid conflicts between
packages, (2) avoid the need to re-do the uid/gid allocation for 35+
packages, and (3) not require manual cooperation between groups of
people in the future.