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 UMeqKaW971/2bAAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 00:26:13 +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 wBd7JaW9718fHgAAB5/wlQ (envelope-from ) for ; Sat, 02 Jan 2021 00:26:13 +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 DAED89403AC for ; Sat, 2 Jan 2021 00:26:12 +0000 (UTC) Received: from localhost ([::1]:55514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvUkF-0004GL-Kl for larch@yhetil.org; Fri, 01 Jan 2021 19:26:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53432) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvUk6-0004EG-LM for bug-guix@gnu.org; Fri, 01 Jan 2021 19:26:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:51743) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvUk6-0001yJ-E0 for bug-guix@gnu.org; Fri, 01 Jan 2021 19:26:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kvUk6-0005v5-8o for bug-guix@gnu.org; Fri, 01 Jan 2021 19:26:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#45571: Fwd: Re: bug#45571: Support stable uids and gids for all accounts In-Reply-To: Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 00:26: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: Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.160954713722716 (code B ref 45571); Sat, 02 Jan 2021 00:26:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 00:25:37 +0000 Received: from localhost ([127.0.0.1]:35056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvUjg-0005uI-Eu for submit@debbugs.gnu.org; Fri, 01 Jan 2021 19:25:36 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:10623) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvUjd-0005u7-HU for 45571@debbugs.gnu.org; Fri, 01 Jan 2021 19:25:35 -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 4D72jQ4Hfjz1LBSH for <45571@debbugs.gnu.org>; Sat, 2 Jan 2021 01:25:30 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D72jQ4Hfjz1LBSH DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609547130; bh=OuswwNIyfkvYog47WMa/+s/0zHe9GdEvb1HffqzXZjA=; h=Subject:From:Cc:Date:References:From; b=tmH/MZJDrLcklrIWBNOT2SED1a0HKQnI8bMD1QI3fGszJzkYA+7t5Pm4rnFGCXsSA iu5jPpUivwtXXNmLIViaGqBGpdI/Sgv8ZaL8hNiGLizXZNeaODkG+OWZa7lYAgkMg/ qFCGlUB7BJ9r43INUyOL1lcTTuXZ9vaD6XZVqfj4= Message-ID: <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> From: Leo Prikler Date: Sat, 02 Jan 2021 01:25:29 +0100 References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> Content-Type: multipart/mixed; boundary="=-I6jPGWIToLDRc+qoSG1n" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -0.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: 0.77 Authentication-Results: aspmx1.migadu.com; dkim=fail (body hash did not verify) header.d=tugraz.at header.s=mailrelay header.b=tmH/MZJD; 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: DAED89403AC X-Spam-Score: 0.77 X-Migadu-Scanner: scn1.migadu.com X-TUID: 2PCvRuXxMjSU --=-I6jPGWIToLDRc+qoSG1n Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Forgot to CC the ML. --=-I6jPGWIToLDRc+qoSG1n Content-Disposition: inline Content-Description: Weitergeleitete Nachricht =?UTF-8?Q?=E2=80=93?= Re: bug#45571: Support stable uids and gids for all accounts Content-Type: message/rfc822 Message-ID: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> Subject: Re: bug#45571: Support stable uids and gids for all accounts From: Leo Prikler To: Danny Milosavljevic Date: Sat, 02 Jan 2021 00:16:45 +0100 In-Reply-To: <20210101212242.00252cac@scratchpost.org> References: <20210101184838.21869359@scratchpost.org> <2f2fd3d66066b23f31f7db465aea65478ef81e87.camel@student.tugraz.at> <20210101212242.00252cac@scratchpost.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Danny, Am Freitag, den 01.01.2021, 21:22 +0100 schrieb Danny Milosavljevic: > Hi Leo, >=20 > On Fri, 01 Jan 2021 19:44:12 +0100 > Leo Prikler wrote: >=20 > > 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? >=20 > Considering the goal of Guix, it's weird that with Guix, one needs to > store&restore /etc/passwd at all. It's state, but not very useful > one. > I mean that's how it is right now--but it's still weird. >=20 > With /etc/shadow maybe there's a slightly better case, but note that > the key > to find stuff in /etc/shadow can't be the uid--the uid isn't even in > there! AFAIU yes, it's state, but not one that Guix can simply do away with.=20 There is not yet a syntax for keeping secrets, which would be needed to fully populate /etc from config.scm. Perhaps we'll get there some day. Also IIUC, account names are supposedly unique, hence my proposed patch to #45570. > > How is that explicit? The % even implies, that it's considered > > internal to the definition. >=20 > Explicit means that the user-account record is initialized right > there (every > time account-service-type is extended), by a literal. >=20 > And it is. You can see it plain as day in the guix git repo where > account-service-type is used in gnu/services/ . >=20 > Implicit would be if some code would generate this > record > on-the-fly, usually leaving stuff hard to change by the maintainer. Fair enough, that's explicit in some sense, but not explicit if we take the config.scm as the point of reference. Since there's no way of explicitly setting it from there without advanced wizardry. > '(user-account (name "x") ...)' is about as explicit as it gets for a > record. >=20 > The "%" in the name of the binding changes nothing in the literal > value. >=20 > And it indeed is possible to add (uid 4711) in the literal and it > will work > just fine. I'm aware you're joking, or at least I hope you are, but I shouldn't have to point out why hardcoding ids into those literals is a bad idea. > > 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. >=20 > Oh, you want internal service users to be USER-configurable. Indeed > that is > also what Jason suggested in the initial mail. >=20 > But I think that that would put undue burden on each user and is > really just > a workaround. > I would really like to caution against us doing a "whack a mole" > development > approach, where workarounds like that are introduced to work around > bugs > without understanding the underlying causes. So I disagree that > having > internal service users be user-configurable is a good idea. "Undue burden on each user" is a bit exaggerated, considering that the defaults work fine for most. Making them user-configurable would even allow hardcoding a default ID, because users would be able to change that ID if they wanted a different one, eliminating even more reasons to configure them if not for the reason of "because I want to". I also disagree, that this is a problem, that we can solve as Guix System alone. Even if we were to implement your hash idea, other distros would still be keeping their numbering systems. If you share an NFS with a legacy system, you'd still need a mapping or inherit accounts from their settings -- neither of which sound great, but compromises have to be made. In that sense, I agree with Jason that it is a problem, that you can't set service [GU]IDs when you want (or need) to. The question is how to best make them configurable. > > 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? >=20 > Sure, but that's a last resort. Better is to eliminate state if > possible. Keyword being "if possible". It is currently not possible to eliminate shadow. > > > (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. > > >=20 > > > (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. =20 > > 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)? >=20 > It generates uids using a counter, so it depends on what order > user-accounts are created in by Guix, which depends on the order the > user > specifies services in /etc/config.scm and on the order to user > accounts > are specified in gnu/services/ by guix maintainers. Then the service > executable (potentially) goes on to create files using those uids. >=20 > That means that if you remove or reorder service references in > /etc/config.scm, > the uids "want" to change. The only reason they don't change is > because the > logic prefers the existing /etc/passwd's uids--a stopgap measure at > the last > second to prevent total chaos. >=20 > Does any of this sound good to you? Keeping value judgements aside, it does sound deterministic. Relying on order is also not that big of a deal if you have ways of ensuring order, but you'd also have to ensure, that the expected order is the same as the one actually used, and that's significantly harder to do. An example: You could expect user accounts to be numbered in the order they appear in the field, but you could also expect them to be numbered in reverse order (because services can add accounts and they're usually consed). In that sense, yeah, relying on order is certainly not optimal. > I mean, strictly speaking, it's better than the alternative--but > that's a low > bar. >=20 > Better would be a making the uid field mandatory and/or generating > each uid > from the respective name. Statistically speaking hashes collide sooner than incrementing numbers do. Granted, they might work as mitigation, but they're no solution on their own either. > > As far as I understand it, same config.scm + same > > /etc/{passwd,group,shadow} =3D> same /etc/{passwd,group,shadow}. >=20 > That is the intention of (gnu system shadow), I think. You mean (gnu build accounts), right? > I can't say whether that's the case in practice now or not. It > certainly was not the case a few > years ago where I did run into the same problem (a necessary > condition for > the problem to manifest is that the services change--but my > /etc/config.scm > services forms have been stable for a long time now, and Guix > upstream also > doesn't change service definitions a lot anymore. So who knows?). Well, the point here was not to state how outputs differ when the inputs differ, but what happens, when they stay the same. I have another machine, that I carried over from a Gentoo install using different user names, and there I have a different UID from this machine, where I did a clean install (and it has stayed the same UID since). IOW this appears to be functioning as intended. Regards, Leo --=-I6jPGWIToLDRc+qoSG1n--