On 15 May 2017 at 23:04, Val Kulkov <val.kul...@gmail.com> wrote:
> On 15 May 2017 at 10:59, Yousong Zhou <yszhou4t...@gmail.com> wrote:
>> On 15 May 2017 at 22:41, Val Kulkov <val.kul...@gmail.com> wrote:
>>> 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.
>>
>> Exactly!
>>
>>> 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.
>>>
>>
>> Maintain a big list and package it in every built firmware so that
>> auto-allocation can skip them? It's overkill I guess.
>>
>> How about just converting existing hardcoded uid/gid assignment to use
>> only auto-allocation method and also drop the USERID=un=uid:gn=gid
>> support from default_postinst. Will this break something
>> significantly?
>>
>> yousong
>
> I was thinking about a Wiki page which would be consulted by reviewers
> each time a new package is considered for the addition to the packages
> repo. This way, there is no need to include a big table into the
> firmware, and there is no need to change the existing assignment
> unless there is already a conflict.
1. Hardcoded uid 105 is not better than auto-allocated uid 101 and
only slightly better than auto-allocated uid 1001
2. If the list is not present in the device at allocation time, I
guess the situation you presented above cannot be avoided
yousong
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
