[gentoo-dev] last-rite: dev-java/milton{,-mail}-api
# Volkmar W. Pogatzki (2021-11-14) # java packages without consumers, Removal in 30 days. dev-java/milton-mail-api dev-java/milton-api
Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval
On Sun, Nov 14, 2021 at 09:15:36PM +0100, Thomas Deutschmann wrote: > On 2021-11-11 11:59, Ulrich Mueller wrote: > > We could: > > > > - Open some part of the range between 500 and 1000. For example, > >500..799, which would leave 200 IDs for dynamic allocation. > > > > - Open part of the range 60001..65533. Not sure if all software will be > >happy with that. > > > > - Admit that the concept of static allocation has failed, and return to > >dynamic allocation. > > Only the third option is really possible. FWIW, I agree with this sentiment. 1/ Static allocation does not really solve a problem. Not really not nowadays 2/ We cant keep adding new IDs to a distribution as new software gets added - one side is unbounded. This is losing game. Switching back to dynamic allocation seems to be the best option. -- Eray
Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval
> On Sun, 14 Nov 2021, Thomas Deutschmann wrote: > On 2021-11-11 11:59, Ulrich Mueller wrote: >> We could: >> - Open some part of the range between 500 and 1000. For example, >> 500..799, which would leave 200 IDs for dynamic allocation. >> - Open part of the range 60001..65533. Not sure if all software will >> be happy with that. >> - Admit that the concept of static allocation has failed, and return >> to dynamic allocation. > Only the third option is really possible. > The first option (500-1000) would be technically possible but would > clash with knowledge people gained in the past and would violate LPIC > (=making Gentoo even more special and unusable for companies relying > on certifications). Why would that be? We chose the original split point quite arbitrarily to be 500. What is different about adjusting it upwards now? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval
On 2021-11-11 11:59, Ulrich Mueller wrote: We could: - Open some part of the range between 500 and 1000. For example, 500..799, which would leave 200 IDs for dynamic allocation. - Open part of the range 60001..65533. Not sure if all software will be happy with that. - Admit that the concept of static allocation has failed, and return to dynamic allocation. Only the third option is really possible. The first option (500-1000) would be technically possible but would clash with knowledge people gained in the past and would violate LPIC (=making Gentoo even more special and unusable for companies relying on certifications). In addition, it would just delay the problem we currently have and not solve/address it. Allowing ranges 60001+ is technically not an option. Expect that daemons using IDs >1000 will run into problems. Expect security problems because known system user range is hardcoded in many places so 60001+ is unexpected. This will really make Gentoo 'unique' in a really bad way and will break with everything which is/was being taught/documented in the world. Let's face it: The idea of static ID allocation didn't scale. Let's stop this experiment before it is too late. Like you know, I always ask why someone is proposing a change, i.e. asking for the motivation. The main driver behind static IDs was that when you are maintaining multiple systems, that if IDs are identical, it will make life a little bit easier because you could copy files from service A on system 1 to service A on system 2 without the need of adjusting permission afterwards. But is this really a problem? From my POV it isn't: 1) If this really was bothering you, you already had a solution in place. Keep in mind: Most setups don't just consist of Gentoo/Debian/RHEL-only... you usually have a mix of setups so you need a solution which works everywhere so you don't need that 'feature' Gentoo offered (not to mention that you probably have something like AD in place which will make things like that very easy). 2) Pay attention to the way how you do stuff today. You will not create systems manually anymore (and if you do, you would just clone so there isn't even a need for this). You will automate this in scripts and use tools like Ansible, Salt, Chef, Puppet and of course, Dockers (which is basically a script) and like mentioned, AD. From my POV I cannot imagine a single reason why we should stick to this idea and invest more time into it with the risk of making Gentoo more unique causing more _severe_ problems in future. Anyone who wants to keep this around and wants to extend UID ranges instead should answer the following questions: 1) How are you going to solve the mentioned problems? 2) Why do you believe this feature is worth all the trouble? 3) At the moment we can stop. But once we start altering systems to mark additional ranges for system users there is _no_ easy way back anymore. Any blow up will probably require user to reinstall their entire system... -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval
> On Thu, 11 Nov 2021, Ulrich Mueller wrote: > In any case, we have run out of GIDs: >Recommended GID only: none >Recommended UID only: 272 >Recommended UID+GID pair: none >Free UIDs: 15 >Free GIDs: 0 >Free UID+GID pairs: 0 > The question is of course how we should move forward. Certainly, using > IDs below 100 cannot be the solution, as we would run out of these very > soon. > We could: > - Open some part of the range between 500 and 1000. For example, > 500..799, which would leave 200 IDs for dynamic allocation. > - Open part of the range 60001..65533. Not sure if all software will be > happy with that. > - Admit that the concept of static allocation has failed, and return to > dynamic allocation. By today's council decision, the whole range from 101 to 749 is now available. The used_free_uidgids.sh script has been updated accordingly. There seem to be some issues with system IDs above 6 especially with systemd. We'll try to sort these out before we run out of IDs again. Ulrich signature.asc Description: PGP signature
