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 0D5FA139085 for ; Sun, 29 Jan 2017 03:42:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3F30914231; Sun, 29 Jan 2017 03:42:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E6A88224199 for ; Sun, 29 Jan 2017 03:42:06 +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 7034933FECD for ; Sun, 29 Jan 2017 03:42:05 +0000 (UTC) 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> <6bac1312-60f9-3ce1-542b-0635b4a37c6b@gentoo.org> From: Michael Orlitzky Message-ID: <4ebf0ddd-c4b0-31ac-a783-efa95f9d6be0@gentoo.org> Date: Sat, 28 Jan 2017 22:42:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 7a8c1f25-3645-408d-9929-3de783f18482 X-Archives-Hash: 50ac4c81756c2048a47335afb6868eaf On 01/28/2017 10:23 PM, Gordon Pettey wrote: > > That's nonsense for reasons already mentioned by rich0. UIDs don't change > except in the case of an admin doing it manually. > It shouldn't be common, but it can and will happen once you put users in ebuilds. As an example, imagine an "echo" daemon that listens on a port and echoes every line of text sent to it. When building the daemon, you compile it --with-uid=, and it runs as that restricted user with access to nothing. In the ebuild, you depend on sys-user/echo, and compile the daemon with the current UID for that user. Now a year later, someone makes a new revision of sys-user/echo and gives it a new fixed UID. Oops, your daemon broke. How do you fix it? Rebuild it. You want to rebuild the daemon whenever the UID in the sys-user/echo package changes. That's exactly what subslot deps do. Disregard whether or not it's stupid to do, or whether it will work in all cases. *If* a system user *does* change its UID, then you almost certainly want to rebuild the packages that depend on it. That can be done if everything has a fixed UID determined by a variable in the ebuild, and the new user is guaranteed to get that UID.