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