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 726E1139085 for ; Fri, 27 Jan 2017 20:09:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 97FE9254034; Fri, 27 Jan 2017 20:09:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 541B625402E for ; Fri, 27 Jan 2017 20:09:42 +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 71AC0341650 for ; Fri, 27 Jan 2017 20:09:41 +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> From: Michael Orlitzky Message-ID: <15866eb3-cd3f-8f4d-dd6c-b4e9d6a9bc78@gentoo.org> Date: Fri, 27 Jan 2017 15:09:38 -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: 43be74b1-f63c-4c80-8974-6803f826e4b1 X-Archives-Hash: 73b89311c006d3ea5999c007fea93f2e On 01/27/2017 02:53 PM, Rich Freeman wrote: > > I'm not saying we can't have random assignment for things where it > doesn't matter, or fall back to random assignment, but it seems rather > silly to go to all the trouble to have blockers when it would be just > as easy to not have a conflict in the first place... > > Telling users that they can't have postfix and apache on the same box > because nobody can be bothered to pick IDs that don't collide seems > like an arbitrary imposition. Agreed, blockers should be a last resort. If neither postfix nor apache cares about its UID (they don't), then certainly somebody should change one of them. My first impression is that any package that doesn't care about its UID should default to "first available", but if that causes problems, then that's exactly the sort of use case I'm looking for. If it's a big problem, we can have devs pick an unclaimed UID and stick with it. Or, if there are 5 users total who need the "apache" user to have UID 80 across every machine, then it might just make more sense to tell them to use an overlay to override sys-user/apache. Keep in mind that currently, if the UID you want isn't available, user.eclass will shrug and give you a different one. No one can really rely on consistent UIDs now, but it's not fair to dismiss the idea because maybe that's one of the things the GLEP was supposed to fix.