Resending to the list properly as planned...
I've modified one of my packages (mosquitto) to use the autoassignment style, as it never cared about the actual uid/gid. However, is this really the expected behaviour? # cat /etc/passwd root:x:0:0:root:/root:/bin/ash daemon:*:1:1:daemon:/var:/bin/false ftp:*:55:55:ftp:/home/ftp:/bin/false network:*:101:101:network:/var:/bin/false nobody:*:65534:65534:nobody:/var:/bin/false avahi:x:105:105:avahi:/var/run/avahi:/bin/false dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false mosquitto:x:100:102:mosquitto:/var/run/mosquitto:/bin/false <<< 100:102?? I know I don't care, but getting 100 for uid and 102 for gid seems somewhat unexpected? Is it issuing ids from the same sequence or something? Sincerely, Karl Palsson Yousong Zhou <yszhou4t...@gmail.com> wrote: > On 16 May 2017 at 00:02, Val Kulkov <val.kul...@gmail.com> > wrote: > > 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. > > Updating 35+ packages is easy with a few lines of shell > scripting. > > > 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. > > Thanks for the reminder. It feels secure that you know someone > is watching your back. If the changes are to be made for good, > we should of course fix those beforehand those we already know > will break. As for the unknown, how bad and in what scale and > how high the possibilities they will break? > > > > > 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. > > > > Future posts may refer to this one as "these are legacies of a > previous decision for historical reasons". > > Thinking that we have talked too much and given enough > proposals in this thread, I prepared a doc trying to do a quick > sum up. Please give further comments there. Hopefully we can > come to a conclusion and take actions thereafter. > > https://docs.google.com/document/d/15kD_-9wCW5mjI8aJaCT03Uoxde3rrtCdZWcaz-5mEtA/edit?usp=sharing > > Regards, > yousong > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
signature.html
Description: OpenPGP Digital Signature
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
