From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id n3I+Ey2T8F+SdwAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 15:37:17 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id IIqcDi2T8F8NbwAA1q6Kng (envelope-from ) for ; Sat, 02 Jan 2021 15:37:17 +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 93E229402A9 for ; Sat, 2 Jan 2021 15:37:16 +0000 (UTC) Received: from localhost ([::1]:41022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvixu-0002c1-Aw for larch@yhetil.org; Sat, 02 Jan 2021 10:37:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47250) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvixi-0002bh-Ls for bug-guix@gnu.org; Sat, 02 Jan 2021 10:37:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:48908) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvixi-00067v-EN for bug-guix@gnu.org; Sat, 02 Jan 2021 10:37:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kvixi-00022H-Bg for bug-guix@gnu.org; Sat, 02 Jan 2021 10:37:02 -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:37: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: Jason Conroy Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16096017647751 (code B ref 45571); Sat, 02 Jan 2021 15:37:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 15:36:04 +0000 Received: from localhost ([127.0.0.1]:60454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviwl-00020w-NF for submit@debbugs.gnu.org; Sat, 02 Jan 2021 10:36:04 -0500 Received: from mailrelay.tugraz.at ([129.27.2.202]:41063) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviwi-00020U-C6 for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 10:36:01 -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 4D7Qvx07BFz1LLyX; Sat, 2 Jan 2021 16:35:56 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4D7Qvx07BFz1LLyX DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1609601757; bh=A71hr1tziO+FjWpB+Id8BND5x5AoZvKMsCuPGhCaOws=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Omj0n0cD9hH2zNLeKzKoAGqmaXlcAjcyOdZk/YR8U46HvZGPLkaEr5eRaVJXrU2Y1 Erng2+LtZGjzzY3DfaR2V1n8TSnNJSs/AZYFfZN29mea3QHSSnWBg10u3W7R5k3YRD EeyCv52BQXkvlhf1gc9kBvMQ+FEINNeeEpn/XoiY= Message-ID: From: Leo Prikler Date: Sat, 02 Jan 2021 16:35:56 +0100 In-Reply-To: References: <58174c197a7b42b29927c492d25e28c684d199ea.camel@student.tugraz.at> <90ec1e8c2daab55d0e41b0fcd61706418789b2a8.camel@student.tugraz.at> <20210102024054.158bb3ba@scratchpost.org> <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> <250d033edc273b0f89e2bd37a331a3f961a8d785.camel@student.tugraz.at> 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=Omj0n0cD; 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: 93E229402A9 X-Spam-Score: -1.23 X-Migadu-Scanner: scn1.migadu.com X-TUID: HUgGRw9nQGOP Hello Jason, Am Samstag, den 02.01.2021, 09:52 -0500 schrieb Jason Conroy: > On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler < > leo.prikler@student.tugraz.at> wrote: > > Hi Jason, > > Am Samstag, den 02.01.2021, 09:02 -0500 schrieb Jason Conroy: > > > On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler < > > > leo.prikler@student.tugraz.at> wrote: > > > > Hi Danny, > > > > Am Samstag, den 02.01.2021, 02:40 +0100 schrieb Danny > > > > Milosavljevic: > > > > > Hi Leo, > > > > > > > > > > On Sat, 02 Jan 2021 00:16:45 +0100 > > > > > Leo Prikler wrote: > > > > > > > > > > > > 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, > > > > > > > > > > What? It's perfectly reasonable for a distribution to have > > > > stable > > > > > system > > > > > user ids. > > > > > > My reaction to this was not that defaults are bad, but that > > > dispersing numeric literals throughout the code is. Collectively > > > these values specify the contents of a registry, so that registry > > > might as well be located centrally. Or at least, there should be > > some > > > mechanism to ensure that two services can't claim the same > > default > > > ID, otherwise the collision will not manifest until somebody > > > instantiates a system with the colliding services. > > I think it would suffice to raise a condition from shadow.scm, much > > like my proposed fix for #45570. As far as development is > > concerned, > > one could add a check to see, that no conflicts exist between > > services > > extending account-service-type. > > Assuming that authors of new services tend to choose the lowest free > ID, is this validation sufficient to ensure that two services checked > around the same time by different authors won't collide? No, you'd need to lint the services in the pre-push hook. That would not be the biggest deal though, we already authenticate the commits and check whether the NEWS file is broken before pushing, for instance. I believe it could also be checked without actually instantiating that system, but don't quote me on that. > > > > 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), with reasonable defaults including > > numeric > > > > UIDs and GIDs (at least) for essential services such as GDM > > sounds > > > > like > > > > the best option. WDYT? > > > > > > > > Regards, > > > > Leo > > > > > > 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. > > In this case I'd agree with Danny, that asking users to update two > > fields to get one service working puts an excessive burden on > > them. > > Leo, I'm not sure what you mean by updating two fields. Are you > saying that some services already permit manual selection of UIDs? I > was proposing setting that value in the "users" section of operating- > system (or elsewhere) rather than setting it in the "services" > section, but not both places. As far as I'm aware, no service so far do that, but there are some, that don't set up the user (e.g. mpd). However, I don't think, that's the way to go for services like gdm. If you decoupled the gdm user and group from its service specification, you'd need to modify three operating-system fields to add gdm as opposed to one. If the gdm user and group were configuration, you could instead specify them with modify-services or gdm-service-type itself. > Since Guix already uses a central allocator for UIDs and GIDs > (implemented using simple counters), I was imagining a model where > the decision is still made centrally, but with different inputs: 1) a > global mapping from user/group name to default ID; and 2) a similar > name-to-ID mapping in operating-system where users specify their > overrides. I'm not sure how well that'd work together with account-service-type. You'd have to find a novel way of extending it, that's for sure. > > To > > be fair, I don't even necessarily think, that making the full > > account > > configurable is a good idea, unless someone wants to argue, that > > there's value in potentially giving those accounts shell access. > > The thought of making other parts of the account configurable > occurred to me, but I couldn't come up with any serious use cases > either. As far as I'm aware, nologin exists for a good reason. Regards, Leo