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

[Tobias Welz]

Hello,

In general I don't mind auto-allocation - it's somehow best for (PC) 
distributions.

I'm not sure if the same applies to embedded systems and OSes like LEDE 
- at least with static backing up of passwd/shadow files.

Wouldnt't a user (developer) expect to backup the settings and restore 
it to a different system and everything still works.

If uids/gids are auto-allocated - it looks to me that there is no 
guarantee that the backup will work - or did i miss something?

If not, there would be the need to do some post-processing after restore 
to somehow fix gids/uids to make everything work again; but it will be 
an extra level of complexity.

I had a look on Daniels inspiration - I think something like that makes 
more sense.

Regards Tobias


On 15.05.2017 18:02, Val Kulkov wrote:
> 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.
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev