On 15.05.2017 18:02, Val Kulkov wrote: > 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.
I know for Unbound package the hard coded GID/UID doesn't functionally matter. Many other packages seem to be the same. You need a non-root user to drop down to. You also don't want one common other user or else "nobody:nogroup" becomes the new root (in a way). It may not be so difficult to get cooperation. Trouble occurs supporting LEDE vs OpenWrt split. Some people want to SDK only a few latest add on packages, but keep their preferred stable base. 15.01.1 doesn't support install UID/GID assignment. There are other divergences. Compatibility across the split generates non-ideal design choices. It makes maintaining optional packages more and more difficult. Once that matter is closed, this symptom effect may all but solve itself. - Eric _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev