From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id MPrDAkqP8F/lawAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 15:20:42 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 0ZgSOkmP8F91CwAAbx9fmQ (envelope-from ) for ; Sat, 02 Jan 2021 15:20:41 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 88FC29402A9 for ; Sat, 2 Jan 2021 15:20:41 +0000 (UTC) Received: from localhost ([::1]:35118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvihr-0007Sa-2d for larch@yhetil.org; Sat, 02 Jan 2021 10:20:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44756) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvihG-0007Ic-UX for bug-guix@gnu.org; Sat, 02 Jan 2021 10:20:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:48898) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvihG-0008Kt-4V for bug-guix@gnu.org; Sat, 02 Jan 2021 10:20:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kvihF-0001cE-VN for bug-guix@gnu.org; Sat, 02 Jan 2021 10:20:01 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 15:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45571 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Danny Milosavljevic , Jason Conroy Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16096007456136 (code B ref 45571); Sat, 02 Jan 2021 15:20:01 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 15:19:05 +0000 Received: from localhost ([127.0.0.1]:60444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvigK-0001au-OQ for submit@debbugs.gnu.org; Sat, 02 Jan 2021 10:19:05 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:34354) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvigI-0001aS-2n for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 10:19:03 -0500 Received: from nijino.local (217-149-174-13.nat.highway.telekom.at [217.149.174.13]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4D7QXL4T4Yz1LLyX; Sat, 2 Jan 2021 16:18:58 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D7QXL4T4Yz1LLyX DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609600738; bh=m911qi9GC1TmLaXhkVWLWJriPK/tzI9NoCr/ILL54yY=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=VSO4gfVCNaPjl8Ee026i1GwWnukcd1GGYr1vbi8aez0Vmk/9n4S51/Kzrw+CffaJQ /uJPA5bV839BZwZpzQQ3e0sRiIM7J5nr8h4d/gfB8ZJ43zsilO3BmgA8ST4P9Dtff/ 0febWounrdSIfwFn2pgmbLXYMBiRShsTsvhCdBfM= Message-ID: From: Leo Prikler Date: Sat, 02 Jan 2021 16:18:57 +0100 In-Reply-To: <20210102155002.2360e505@scratchpost.org> References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> <20210102155002.2360e505@scratchpost.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 45571@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.23 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=tugraz.at header.s=mailrelay header.b=VSO4gfVC; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 88FC29402A9 X-Spam-Score: -1.23 X-Migadu-Scanner: scn1.migadu.com X-TUID: b2FfxRV3i15u Hi Danny, Am Samstag, den 02.01.2021, 15:50 +0100 schrieb Danny Milosavljevic: > [...] > I agree, if in addition. > > (Or if a registry is undesireable, calculate the uids by user name. > These are the possibilities. If hashing user names is too uncommon > on > UNIX elsewhere, I say that we have no /usr or /lib, so we are not > exactly doing > common things in Guix because they are common--what we do really > depends on the > merits) I don't think hashing has much merit if you have the range of 100-1000 to work with. Using the full 32 bit integer range also feels like a hack just to enable hashing, and even then hash functions targeting 32 bit integers are not known to be the most secure in this world. In other words, hashing user names into IDs is little more than theatre and while it can certainly mitigate the underlying issue in *some* cases, it is not by itself a solution. > > > From the solutions we do have so far, I believe that making user > > > accounts an explicit part of service configuration (in what shape > > > may > > > still be up for debate), > > Not everything needs to be user configurable. You suggest having > these kinds > of things especially user-configurable as a work-around for them not > being > stable, right? Or do you want it in general? I believe there might be a general utility for that if we're not going to use an existing passwd as oracle. In that case, you would need a way of claiming those IDs from the config.scm. Other than that, I believe you pointed out an NFS example, where it could also be beneficial to sync up user/system accounts with the IDs they have on other machines within the network. Of course, if all machines within the network use Guix, that point is moot, but there might be a case when you want to play nice with that one old Debian server. > I would like to avoid them here, if only needed for that reason. > > (Also, if they are user-configurable, then it's much easier for uid > collisions > to happen than if Guix manages them) Sure, but either way we'll need a collision checker, will we not? > So after thinking about it some more, I disagree that that is the > best option > for this specific problem. > > In my opinion, the best option here is all of these things: > > (1) To document that you need to seed /etc/passwd (for Docker etc) > (2) For guix system container to default to the host's /etc/passwd > and > (3) For guix system container to add and retain (!) its own > /etc/passwd for > accounts only it has (merged together with the host's /etc/passwd for > ease > of implementation) That's also a solution and I think I'd prefer that over spamming IDs throughout the codebase. > The suggestions I made before that would obsolete /etc/passwd storage > got > watered down to a version where they don't obsolete /etc/passwd > storage and > thus I oppose doing them in that form. It would be making the stuff > more > complicated--and now you'd have TWO /etc/passwd: > > * one /etc/template-passwd (for the uid registry) > (might as well integrate that into guix as a scheme file, though), > * and one /etc/passwd with the currently created users. > > This seems to be excessive just for making uids stable. FWIW I think taking the passwd-seed as a file-like object, that defaults to using the host's /etc/passwd might work here, but I'm not completely sure. > > That seems reasonable to me. As for representation, I think there's > > value > > decoupling these settings from a service's own config so that > > support for > > custom UIDs/GIDs remains consistent across services. > > Is there a need for using custom service UIDs? > I think if so, that is independent of this bug report, which asked > for > stable UIDs and GIDs. I agree, the discourse regarding that has been muddled a bit, but since custom implies stable I don't think this option can be completely discarded. Of course, both stability and customization are also given by a passwd-seed, so if we choose that implementation, other means of customization might not be needed. Regards, Leo