From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-79389-garchives=archives.gentoo.org@lists.gentoo.org>
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 0983A139085
for <garchives@archives.gentoo.org>; Sun, 29 Jan 2017 08:29:10 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id C9BB0234095;
Sun, 29 Jan 2017 08:29:01 +0000 (UTC)
Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244])
(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 6486B224199
for <gentoo-dev@lists.gentoo.org>; Sun, 29 Jan 2017 08:29:01 +0000 (UTC)
Received: by mail-wm0-x244.google.com with SMTP id r126so69439961wmr.3
for <gentoo-dev@lists.gentoo.org>; Sun, 29 Jan 2017 00:29:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding;
bh=6Cp8vfq5KDdG2USOcjvrQIn/9B9us32R58iWzNeEpgs=;
b=S2T6Nbi0b4qR0WnZORAQZ1ugFeHFD6OXvwDVm0ab0CfX0FxJzTDFly08auGym2A8E0
LqHNZwe4OKrNwDJcU+zlyDyjAxoyhC8wkLRpps7lM2PFMNF0QiZ6ErJkz7bcPu/jgkyk
haaXmR58rMX/WqVaMgvLPnLrMAfu7s5181WnRsdeRYXsovCzTBknYCGEp9Pd9biWtJjg
AY7M9L13vye5yahMsgddryUS/InbeL50pzH7C5HGGXk2F50pc85qNBLwdfWqSWjhIUZK
NQpC3G+OA+5FijLy0IKpSB2kpx1tq1iUUMkUQ4KAR07v/l54Mm9O+H3GUyfUrTCNaYhB
z6hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=6Cp8vfq5KDdG2USOcjvrQIn/9B9us32R58iWzNeEpgs=;
b=NMBnQRFO6LctYfiOT9oblLK3T0h/rIbiwvXzl1rWgopDbkUPjAnWIQjXqucunmRmdc
WUsEClyQSTTmlVTZDlgvmovlu8Zl1Bdzn76Tib7o98kJMoXFS1nRRVCwGRcopigKkTOV
Wz2QGFD82BgBmOAsfqi2MC7LF3AEYeE3AZqN4ub/UA/SbgjC+UgZhLkaPI9eyUi3NSkJ
H4uBjIt2r+F0M0qWifPhWIXgG1k2b7oYlG9vJDz2IDm/aVOENP4seFOgesMtrvo9ZcE3
T/NNlZlss3vbbjTKChAxNx/KM0FCvRhPp5MllqWwEDv0ulMLYuY6U4NOmQbNDf+pPBLW
g/4w==
X-Gm-Message-State: AIkVDXKzbJTbkPfM4HwdwB2bM3ICo4HE/7splUDlmRGcTmsjL+lHuFE0rR5biCYD8S8SGg==
X-Received: by 10.28.155.199 with SMTP id d190mr8827536wme.31.1485678539717;
Sun, 29 Jan 2017 00:28:59 -0800 (PST)
Received: from [172.20.0.40] ([196.212.62.210])
by smtp.googlemail.com with ESMTPSA id i189sm12697381wmg.7.2017.01.29.00.28.58
for <gentoo-dev@lists.gentoo.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 29 Jan 2017 00:28:58 -0800 (PST)
Subject: Re: [gentoo-dev] Requirements for UID/GID management
To: gentoo-dev@lists.gentoo.org
References: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org>
<CAGfcS_=biacBM0xsy0GX3_X0mOAd3BdgHDXYorSBkmwsoQ9sgQ@mail.gmail.com>
<ee24eb83-4430-40ff-07d0-577bc188457d@gentoo.org>
<CAGfcS_=V+xmBU+fFbMQBH39E9-y9CUaZt9Bok80Wg6_jboHcbQ@mail.gmail.com>
<20170127183752.500f8910@patrickm>
<CAGfcS_kcXOa+NC5Eh_qGb95uEaaKsarjsK92jOuTpUB=P5sXxg@mail.gmail.com>
<4a8204d4-929e-6260-957a-dcf8f82f4b24@gentoo.org>
From: Alan McKinnon <alan.mckinnon@gmail.com>
Message-ID: <c350f01e-0bf8-f7b4-cfa0-ce6a9575e5e2@gmail.com>
Date: Sun, 29 Jan 2017 10:26:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.6.0
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Archives-Salt: c6e0f216-e914-4640-91cf-cc3174121c77
X-Archives-Hash: 0a1b2258d37e4fa9f3e5e00fcf95bd9e
On 29/01/2017 03: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=321 as his fixed UID, what
> 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 maintainer
> decides he wants to use UID=102 and I still have tcpdump using it.
>
> * 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.
The general process I would recommend is that if the ebuild finds the user
already exists, leave it, it's UID and it's file ownerships alone, and keep
them as they are. If the user does not exist then create it. Preferably
use a pre-assigned UID/GID so there is some consistency with most other
Gentoo things out there.
If the user already exists, it's presumably because the sysadmin wants
it that way or it was installed that way from an older ebuild. Either
way the ebuild cannot mess around with that. It could output an elog
saying the uid/gid doesn't match the new Gentoo norm, and provide the
commands to run to bring things into line (usermod, groupmod, find /
-user -exec chown, etc, etc)
--
Alan McKinnon
alan.mckinnon@gmail.com