From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id cGtWGc9t719ZbwAA0tVLHw (envelope-from ) for ; Fri, 01 Jan 2021 18:45:35 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id YGUqFc9t71+zLQAAB5/wlQ (envelope-from ) for ; Fri, 01 Jan 2021 18:45:35 +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 CF6B294038E for ; Fri, 1 Jan 2021 18:45:34 +0000 (UTC) Received: from localhost ([::1]:59328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvPQa-00014B-5s for larch@yhetil.org; Fri, 01 Jan 2021 13:45:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33170) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvPQ6-0000y2-Ga for bug-guix@gnu.org; Fri, 01 Jan 2021 13:45:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:51529) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvPQ6-0000Ez-96 for bug-guix@gnu.org; Fri, 01 Jan 2021 13:45:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kvPQ6-0001qk-6j for bug-guix@gnu.org; Fri, 01 Jan 2021 13:45:02 -0500 X-Loop: help-debbugs@gnu.org Subject: 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: Fri, 01 Jan 2021 18:45:02 +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 Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16095266607044 (code B ref 45571); Fri, 01 Jan 2021 18:45:02 +0000 Received: (at 45571) by debbugs.gnu.org; 1 Jan 2021 18:44:20 +0000 Received: from localhost ([127.0.0.1]:34842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvPPP-0001pX-Ub for submit@debbugs.gnu.org; Fri, 01 Jan 2021 13:44:20 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:17052) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvPPM-0001pN-RY for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 13:44:18 -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 4D6v7d536kz1LBMx; Fri, 1 Jan 2021 19:44:13 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D6v7d536kz1LBMx DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609526653; bh=hAk9266j2IogqDV1Tz0Hf4TDTgSRt0SDDWUJ4hQGm4g=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=tOpCG7KU5BIXDk7CnPynBdML+iTuj6sko6nsCn31vBIftXQwaYn+QJyMf07ASe6In 8zW+fldjnIGhKqGAbjiJYwcWgSsGYAninh7GxfrZ52ycQKpwGRzHQ54v18Q3coNYWw ZR8dBz4nV/yrFfuN0yEIiepu5510cTnzpW1puh2I= Message-ID: <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> From: Leo Prikler Date: Fri, 01 Jan 2021 19:44:12 +0100 In-Reply-To: <20210101184838.21869359@scratchpost.org> References: <20210101184838.21869359@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.116 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=tOpCG7KU; 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: CF6B294038E X-Spam-Score: -1.23 X-Migadu-Scanner: scn1.migadu.com X-TUID: 2w8ZZM9+raQI Hi, Am Freitag, den 01.01.2021, 18:50 +0100 schrieb Danny Milosavljevic: > Hello, > > On Fri, 01 Jan 2021 17:20:58 +0100 > Leo Prikler wrote: > > > I don't think changing the way UIDs are allocated by default is a > > good > > solution as that will break many running installations on real > > hardware, that default to those. > > (gnu build accounts), allocate-passwd defaults to keep using the uids > of > existing /etc/passwd entries. So running installations on real > hardware > will not be affected when we change the defaults--otherwise those > installations on real hardware would already have had big problems > regarding > user accounts with the current version of Guix when someone adds a > user account > (system account or not) to them. Then, depending on the order of the > declared > user-accounts, the uids would have swapped. Ah, that puts things into perspective. In other words, the problem is not, that Guix doesn't read /etc/passwd at all, but that it reads the wrong one (the host instead of the guest, so to speak). Should this perhaps be a parameter instead? > > A better solution would be to make > > user accounts and groups explicit configuration wherever account- > > service-type is used, so that it's possible to override them if > > needed. > > They already are explicit. > > For example, (gnu services monitoring) has: > > > (define %darkstat-accounts > > (list (user-account > > (name "darkstat") > > (group "darkstat") > > (system? #t) > > (comment "darkstat daemon user") > > (home-directory "/var/lib/darkstat") > > (shell (file-append shadow "/sbin/nologin"))) > > (user-group > > (name "darkstat") > > (system? #t)))) > > and then > > > (extensions > > (list (service-extension account-service-type > > (const %darkstat-accounts)) > > As you can see, the user and group accounts are already > explicit. What's > more, the uid (and group id) can already be specified right there, > and I > argue that it should be specified right there, and that there should > be a > stable default if it's not specified. How is that explicit? The % even implies, that it's considered internal to the definition. Instead, you'd have (darkstat-accounts config), which default to the current value of %darkstat-accounts, but are configurable at least in the way that they allow you to set their ids. > So to summarize: > > (1) This bug is a real problem, and something should be done about > it. Naturally. > (2) The reason it doesn't currently affect Guix system users is > because there > is logic preferring existing /etc/passwd, /etc/shadow and /etc/group > entries > (which I agree is a good idea). Doesn't help for guix system > container, though. > > Or for NFS network file systems. Any time you have more than one > computer > (even with Guix on it) with a filesystem in the network and regular > users, > you have to have consistent uids or have a lot of weird uid maps per > computer > that someone has to maintain, or worse, an extra service just mapping > them. > Why do that to yourself? In the realm of Guix system, this could be resolved by allowing the user to choose the "seeds" for those files, so to speak (in commands such as init, vm, deploy, etc.), could it not? Especially for (3), carrying over the old shadow from the guest rather than generating a new one with initial passwords sounds like it'd be a necessary precondition for using them with persistent storage. > (3) For /etc/shadow, it also makes sense to keep the existing entry > (the user > name is the key for the search for it btw) because of the password > set. See above. > (4) It makes sense to keep the existing /etc/{passwd,shadow,group} > entries both > for backward compatibility and also for extensibility of guix with > user & group > accounts guix knows nothing about. Not knowing about such accounts sounds somewhat antithetical to Guix, but whatever. > (5) Also for not having this bug with containers, it would still be > better to > just make uid and gid mandatory for "user-account" records. > > (6) Since (5) would move the burden to the user, it would be better > usability > to generate uid and gid in a deterministic manner as a default. Is the current logic non-deterministic in any way other than supporting the reuse of old entries (which you yourself agree is a good thing)? As far as I understand it, same config.scm + same /etc/{passwd,group,shadow} => same /etc/{passwd,group,shadow}. Regards, Leo