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 2EE0E138334 for ; Tue, 10 Dec 2019 14:37:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CABCFE09B5; Tue, 10 Dec 2019 14:37:04 +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 82E47E0977 for ; Tue, 10 Dec 2019 14:37:04 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id 5BCAF34D6A4 for ; Tue, 10 Dec 2019 14:37:03 +0000 (UTC) Subject: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing) To: gentoo-dev@lists.gentoo.org References: <84a435bffe460efd2620ceec0c0405fa18a7937b.camel@gentoo.org> <125e9b9f-ad37-ea5c-c204-9e2c404132a8@gentoo.org> From: Michael Orlitzky Message-ID: <8dd4fc52-45af-ffd4-1eda-e06be01bf962@gentoo.org> Date: Tue, 10 Dec 2019 09:36:56 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 5f3b556c-311a-432b-95b7-0e0131d42cff X-Archives-Hash: 406bbf51dd0befc8e9fc7e58af2b77ac On 12/9/19 3:10 PM, Thomas Deutschmann wrote: > On 2019-12-09 19:48, Ulrich Mueller wrote: >>>>>>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote: >> >>> Like said, if an ID is already taken for any reason on user's system, >>> that's not a problem. acct-* can handle that... there's nothing like a >>> collision. >> >> You can call it "collision" or something else, the fact is that in this >> scenario, the acct-* package won't get its preferred ID. Which is the >> whole point of the migration to static IDs. You can consider this >> unimportant, but why do we have GLEP 81 then, in the first place? > > Heh, I am sorry but I think your expectation is wrong here: > > From my understanding, the authors of GLEP 81 should correct me if I am > wrong, the main idea was to get stable IDs across multiple Gentoo systems. > Since I have been summoned... the stable UID/GIDs were not the main motivation for GLEP81. The big problem it solves is that we had multiple packages creating "shared" users in the same namespace, either (a) without knowing that they were shared, or (b) trying to keep every piece of copy/pasted user data in sync. This lead to some dumb security vulnerabilities, like using the "milter" user for anything that looks at an email. On a mail server you wind up with five unrelated daemons being able to write to each others' private files. For another example, the "ntp" user was fought over by at least two packages that insisted on certain (mutually exclusive) settings for the same user. Whether or not your daemon worked depended on which ebuild was re-emerged last. GLEP81 solves that, and factors out the user data so that multiple packages can share a user without having to copy/paste its settings and keep them synchronized. It also addresses the fact that some users are needed at both build/runtime, while others are needed only at runtime. In the past, enewuser calls were placed randomly in one of pkg_setup() or pkg_preinst(), and you'd wind up with users on your system for packages that failed to build. Now you just depend on the acct-user package in DEPEND or RDEPEND like anything else. The very first RFC didn't even include fixed UIDs, but a lot of people requested them. I can see how it's useful. Every few years, I have to replace a mail server and rsync over the contents of the mail store. On the new server, I have to be very careful that the UIDs match up, which might not be the case depending on the order certain packages were emerged in. It's not too hard to do, but you have to know to do it, and it wastes some time. It'll be great not having to worry about that next time. If developers can spend a few minutes picking out a fixed UID to save users an hour here and there, I think it's worth it, because there are a lot more users than developers.