From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 80919138334 for ; Mon, 9 Dec 2019 17:47:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A56FFE089A; Mon, 9 Dec 2019 17:47:27 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 504E9E0883 for ; Mon, 9 Dec 2019 17:47:27 +0000 (UTC) Received: from a1i15 (a1i15.kph.uni-mainz.de [134.93.134.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ulm) by smtp.gentoo.org (Postfix) with ESMTPSA id AD80334D8BD; Mon, 9 Dec 2019 17:47:25 +0000 (UTC) From: Ulrich Mueller To: Thomas Deutschmann Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing) References: <84a435bffe460efd2620ceec0c0405fa18a7937b.camel@gentoo.org> Date: Mon, 09 Dec 2019 18:47:17 +0100 In-Reply-To: (Thomas Deutschmann's message of "Mon, 9 Dec 2019 17:54:17 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Archives-Salt: a1495ece-1596-46fe-9bb8-a3ae204f3e2a X-Archives-Hash: 9312675153f4827b3a5a9f8d275f3992 --=-=-= Content-Type: text/plain >>>>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote: > Make complete SYS_UID_MIN - SYS_UID_MAX range available for GLEP 81. > The only argument/reason I am aware of, "but 501-999 could be used by > system" (Dynamic allocation by user.eclass), isn't strong enough from my > POV because system administrator can already pick something between > SYS_UID_MIN-MAX so system must be already capable of dealing with such > scenarios. So why do you think this range must be reserved? Isn't > blocking 501-999 just another random choice? > Therefor I would change the recommendation to pick highest free number. > I.e. it should be recommended to pick the lowest free UID/GID pair > instead (just to avoid fragmentation and keep 501+ free as long as > possible). One problem with that is that at some time user.eclass dynamically allocated IDs starting at 101 upwards, and later this was changed to 999 downwards (at different times for UIDs and GIDs). So for existing systems you can expect some range above 101 and some range below 999 to be occupied. So it may not be the best idea to start picking IDs from 101 upwards, which are most likely to collide. If the range below 500 should fill up completely, we can always reconsider. Ulrich --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEZlHkP3TnuTbxrN0HwwkGhRxhwnMFAl3uiKUACgkQwwkGhRxh wnPofQf/WG7fP7BX05UzZjOByqc9fzaHSnWTtmONAbn29x+dXYfg5HquBSFukNvg /OHFitFKp5wOaeK7SRIW0X5VIFCsZ2S+uo5xnrE1ket/at/OLJBkY56tYXzp7oE/ yAKxySTznJBl/waZaS94OuMWh3h7s5WQSsi/WZL9oKnajgpRBiTBlTFsU4N57l43 lMY2LeGFb2Qb8oxGH7FxSQNTQcC3SZ7SWpUvFgBw8n1pw3g/jOhBzllqYRCVIAvN B34J/tztOP6KC8t/r35+p2RD420E/EKqUGmBQQfvAOdOwG4H7mxfwgr8Wu9HdrOA XISK55T4a6zlN9S9L5yJYNwnVtSVtg== =Zfo9 -----END PGP SIGNATURE----- --=-=-=--