Hello,
In general I don't mind auto-allocation - it's somehow best for (PC)
distributions.
I'm not sure if the same applies to embedded systems and OSes like LEDE
- at least with static backing up of passwd/shadow files.
Wouldnt't a user (developer) expect to backup the settings and restore
it to a different system and everything still works.
If uids/gids are auto-allocated - it looks to me that there is no
guarantee that the backup will work - or did i miss something?
If not, there would be the need to do some post-processing after restore
to somehow fix gids/uids to make everything work again; but it will be
an extra level of complexity.
I had a look on Daniels inspiration - I think something like that makes
more sense.
Regards Tobias
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.
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
