On 15 May 2017 at 11:12, Yousong Zhou <yszhou4t...@gmail.com> wrote:
> 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
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).
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
