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.
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
