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 46AD6139085 for ; Sun, 29 Jan 2017 03:05:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 25995234081; Sun, 29 Jan 2017 03:05:41 +0000 (UTC) Received: from avasout02.plus.net (avasout02.plus.net [212.159.14.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AB30B234060 for ; Sun, 29 Jan 2017 03:05:40 +0000 (UTC) Received: from [192.168.6.147] ([209.93.173.178]) by avasout02 with smtp id e35d1u0073rJG9t0135edX; Sun, 29 Jan 2017 03:05:38 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.2 cv=F9YnTupN c=1 sm=1 tr=0 a=4zaNbBhX470b0gJZ7X1HNg==:117 a=4zaNbBhX470b0gJZ7X1HNg==:17 a=13zjGPudsaEWiJwPRgMA:9 a=WbPmnYzAfxEA:10 a=NEID4--WRahAPEX1myUA:9 a=QEXdDO2ut3YA:10 a=bVCnJFO8gWGJXfcuWN0A:9 a=ONNS8QRKHyMA:10 Subject: Re: [gentoo-dev] Requirements for UID/GID management To: gentoo-dev@lists.gentoo.org References: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org> <20170127183752.500f8910@patrickm> <4a8204d4-929e-6260-957a-dcf8f82f4b24@gentoo.org> From: "M. J. Everitt" Openpgp: id=BA266E0525CFAB101523351B4C30334F93C22371 Message-ID: <00e075c1-9668-6224-9be1-d57367853c96@iee.org> Date: Sun, 29 Jan 2017 03:05:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 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 MIME-Version: 1.0 In-Reply-To: <4a8204d4-929e-6260-957a-dcf8f82f4b24@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b52HWFMsIsOrjLLFjKsTNnlGft6n0HQhA" X-Archives-Salt: f0b95777-dbda-42f3-b6fa-08e3bc7a9d0d X-Archives-Hash: b3577a07e7264be7db008099f645ab6c This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --b52HWFMsIsOrjLLFjKsTNnlGft6n0HQhA Content-Type: multipart/mixed; boundary="BvMeEFPQLhMbAUexipPhgCUha6IjxSi6e" From: "M. J. Everitt" To: gentoo-dev@lists.gentoo.org Message-ID: <00e075c1-9668-6224-9be1-d57367853c96@iee.org> Subject: Re: [gentoo-dev] Requirements for UID/GID management References: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org> <20170127183752.500f8910@patrickm> <4a8204d4-929e-6260-957a-dcf8f82f4b24@gentoo.org> In-Reply-To: <4a8204d4-929e-6260-957a-dcf8f82f4b24@gentoo.org> --BvMeEFPQLhMbAUexipPhgCUha6IjxSi6e Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29/01/17 01:56, Michael Orlitzky wrote: > On 01/27/2017 11:21 PM, Rich Freeman wrote: >> It isn't like inconsistent UIDs are the end of the world. However, >> IMO it still makes sense to at least try to standardize such things. >> Really, if you have a package always installing the same user simply >> sticking a default UID without any effort to avoid collisions is >> better than nothing, but having a wiki page where people can register >> UIDs isn't that big a deal. >> > I threw together an ugly implementation so I could play with both > approaches -- random or fixed UIDs by default. The code to get user and= > group management working is of course nice and simple in either case. > Where they both turn to shit is the upgrade path. > > Here's a problem I have no solution for. Suppose we tell everyone to > pick a fixed UID for their user packages. I have a randomly assigned > "tcpdump" user as UID 102 on my machine today. If we roll this out next= > week and the tcpdump maintainer chooses UID=3D321 as his fixed UID, wha= t > happens when I go to install sys-user/tcpdump? Every option is bad: > > * Keep the existing user. Now its UID is wrong. You might say "so > what," but the majority of users on the majority of systems are > going to have this problem, so you have to wonder what we've > gained by deciding on fixed UIDs and then ultimately assigning > them randomly anyway. > > There's the related problem of what to do if the tuxracer maintaine= r > decides he wants to use UID=3D102 and I still have tcpdump using it= =2E > > * Overwrite the existing user with the new one. Your packages all > break. > > * Have the ebuild die(), and tell the user to fix the UID and file > ownership himself before emerge can continue. Good luck with that. > > In the mostly-random-UIDs approach, I have an answer, even if it's not > pretty: I can use the pre-existing UID instead of the next available > one. This still fails if the ebuild author requests a specific > (conflicting) UID, but that should be extremely rare in the random-UIDs= > model. > > Can anyone think of an upgrade path for fixed UIDs? That issue aside, I= > may have convinced myself that fixed UIDs are better. > > I suspect that this would be best handled in an eclass with a stack of functions controlled by USE-flags or an eselect module or something. Seriously outta my league on this one .. but throwing the idea out there for anyone to discuss potential viability or not! --BvMeEFPQLhMbAUexipPhgCUha6IjxSi6e-- --b52HWFMsIsOrjLLFjKsTNnlGft6n0HQhA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJYjVwBAAoJEN7KWvRhIveDC8oQALTdBRQJlARWH/+fbEZZ7ZiJ nhHOC+EmcrIRKGnOY7yACgSpc5xlcby2Z7H1DE+14Af9qGqoquVSW+wHmX4INBBY O91TqbAFiRsaLY5V1vOM5a9ewLmR+jW2GWjmtGSt/IHtO5UBYR+sDgc7dGx979Xn wOE9V+M3ab+7nHvThf2+X2sdF+Cm9WKV/4FUvAC0Moh7o0spZcD755QJlpjj+xo0 Lwl1BHk6c2Jk4hQaYmFZVwClvwVBtKPJZoAEPWfjFWqLpYbGID/5crbUtVrvPxfI +BpQbStSvuq9286296sPGQf4fThooch0brCmR/ihyaD/lw7jPn5g8mQvyFNweWe5 cCJiTZk45aNuNGNR/myrwl3TsdSmZdsRU4O3eEsFhy/yga8YYBUylmNoFrlZyyiU fAxeXc2TUWM6suD/LqUhqfcZ1ChhSjIT+syf45f7vs8egCqKlNaIte3jADTxHNeC yjURkHo3j9O49y5dOo5iICqReDdF9D+urqE4C60ZDS4q03ydEkrLG0am046y5P7R xpw7lYHy/KOoNPFYYPhEUYb3IlauO+6rpFa69/VTfDpL3rSw0Bp7Xx5nkV/ETF5p 9eRggz8m2SWOUJBI49E5/CX1VjiJ5F7AJRPOkzFO/EzuX/MR5SY9cDcQOF1kvOZQ 8mdReCdrBqvZcqkhmJTw =+8Q0 -----END PGP SIGNATURE----- --b52HWFMsIsOrjLLFjKsTNnlGft6n0HQhA--