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 C0642139085 for ; Sun, 29 Jan 2017 22:10:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C680B145CC; Sun, 29 Jan 2017 22:10:20 +0000 (UTC) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 56AEC14527 for ; Sun, 29 Jan 2017 22:10:20 +0000 (UTC) Received: by mail-wm0-x236.google.com with SMTP id r141so8314242wmg.1 for ; Sun, 29 Jan 2017 14:10:20 -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=Pjr55+pRcQBFsCejRJY3nIsP/cIeq2B8mv/OTj8EqrE=; b=XArtGS1jBBDQCI6i2STU5Jx0SUqYA6kGFDitwt9ye6HYUkDwz7J8udeFQWC5Ry9eQU cPtJfAmmrmqBPXKmL1xXgETs6nh1ujgpQ6pdw5WmF0b8ztcss0I9k9J1iPkDoFVD4w31 YUrWyRYYv4idALmQYympE00Y/8MfqFiM2QlfMciRRg423sthxSHz6EkZjQN/dnc+wreA MXTUsSJarZ7quPFy413bpqowfa+SkVwyZnzW+z9hIQdmqHUrSmxsjyq9e2Z5t3jyGvH/ v0f6YIuVDMcFEV6oP8CKpw15tXuT3Dgq5yjGLchIAP1RqeVMBfVsq4YCgQNLbXMvsyjl Pjsg== 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=Pjr55+pRcQBFsCejRJY3nIsP/cIeq2B8mv/OTj8EqrE=; b=pYndK4Q21UZHFJFuu1HCnLgPdoL83DapBs0ZoSScqs6dl3nlbzF3U+1FQFu3JioIjd alvp8hJ2UnVlJiD2SXzpXGjTK9e2geNydMbutzHG1iqz2NUCRpgYAsD8gVCAAaL5qbu7 cZx3AS85Nx4z3sqwiQ9mlkCR6EbyDjPo+7ZtJ5PHysjDPxxBY5GjNGpYvbgRDWfeMtbi YuevO6iOGSjozexCFDLg2oZBlgh9EC3WUNGtjYl4fWu3HKbH1uH5+LV+xgr1EMmXZ0cI odQdpW72Go9srmiwIf+j4idE4Jb3tmxwQ+D/1d2/omgzlyOIwd9UpibUWCfj5mkb4zH9 At7g== X-Gm-Message-State: AIkVDXK/14Mmj0cXqUJZPQKUBFLBkQILo9PVwG4vsYVXuWGbwuCIDgz2+Nvxtvamcm5rrQ== X-Received: by 10.223.135.163 with SMTP id b32mr15819666wrb.184.1485727818711; Sun, 29 Jan 2017 14:10:18 -0800 (PST) Received: from [172.20.0.40] ([196.212.62.210]) by smtp.googlemail.com with ESMTPSA id i73sm15690166wmd.11.2017.01.29.14.10.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2017 14:10:17 -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> <20170127183752.500f8910@patrickm> <4a8204d4-929e-6260-957a-dcf8f82f4b24@gentoo.org> <9bceefb9-f7d2-06a4-2304-d31f627f7656@gentoo.org> From: Alan McKinnon Message-ID: <3fd11559-004c-11f8-609a-923ebc074539@gmail.com> Date: Mon, 30 Jan 2017 00:07:42 +0200 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: <9bceefb9-f7d2-06a4-2304-d31f627f7656@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 09680cd4-4a63-4167-82a6-7ae93cec5cae X-Archives-Hash: f4d3e772fb3ca21cbab944f424ee2859 On 29/01/2017 19:05, Michael Orlitzky wrote: > On 01/29/2017 03:26 AM, Alan McKinnon wrote: >>> >>> 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. > > That's what I've got it doing now... > > >> Preferably use a pre-assigned UID/GID so there is some consistency >> with most other Gentoo things out there. > > This is the only point we have left to consider. To recap, there are > three approaches to try: [snip] > 3 Mostly fixed UIDs, but with a fallback to random ones if you don't > get the UID you want. Here, everyone specifies their "preferred" > UID, and we try that first. If it doesn't work, you get the random > assignment. > > Pros (w.r.t option 2): > > * On a new installation, all of the UIDs that are assigned will > likely be fixed, so you get some of the benefit of the first > option without having to create an overlay. This is my preferred choice > > Cons (w.r.t. option 2): > > * The upgrade path is a little hairier. On an existing system, > we'll be introducing a bunch of new user packages that want > a particular UID but don't get it. On existing systems, the > UID assignment will still essentially be random. That's > problematic for packages that truly need the UID they've > requested. I say drop the upgrade path entirely. Why do you as a dev care? You've made a compelling case that making any changes at all is hairy, so don't even try and automate it. As a mere user I personally would never expect Gentoo devs to deal with this, and if there's a knob in make.conf to enable/disable such a user upgrade path, I'd probably disable it. I've had to do this exercise more times than I care to admit, usually to get multiple machines across a network in sync or to deal with nfsv3, and it's not something I'd ever dare throw a script or ebuild at. If you achieved the simpler status of new installs of packages get the preferred UID if available, then I'm 100% happy and over the moon. Everything else is my problem, not yours (although I appreciate the effort to even make the attempt) > Option #1 is pretty much dead in the water without an upgrade path. > We're considering #2 and #3 at the moment, but they're really not > that different. > > >> 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) >> > > There's no safe way to do that. If you call chown (as root) on > everything in a user-owned directory, that user can just create a > symlink to e.g. /root/.bashrc and you'll give it root. It's really a > miserable time trying to switch ownership of anything safely once it's > been created. Sure it can be done, just don't chown -R ~user. DO it the VERY long way round, file by file. Say you changed user "awesome" uid 300 to 400: find / -uid 300 -exec chown awesome {} \+ It works every time, but involves " find / " - ouch - and you can't do it if the user is logged in or has running processes. This is all for system accounts, so I reckon you have a huge show stopper right there, requiring admin intervention -- Alan McKinnon alan.mckinnon@gmail.com