On 15 May 2017 at 11:46, Yousong Zhou <yszhou4t...@gmail.com> wrote: > On 15 May 2017 at 23:29, Val Kulkov <val.kul...@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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
