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 OArJAxWJ8F/5NAAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 14:54: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 UIn1OhSJ8F96dgAAB5/wlQ (envelope-from ) for ; Sat, 02 Jan 2021 14:54:12 +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 2A1759402A9 for ; Sat, 2 Jan 2021 14:54:12 +0000 (UTC) Received: from localhost ([::1]:47238 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kviIE-0007el-La for larch@yhetil.org; Sat, 02 Jan 2021 09:54:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41484) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kviI7-0007ed-6D for bug-guix@gnu.org; Sat, 02 Jan 2021 09:54:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:48057) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kviI6-00084w-7k for bug-guix@gnu.org; Sat, 02 Jan 2021 09:54:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kviI6-0000jt-67 for bug-guix@gnu.org; Sat, 02 Jan 2021 09:54: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: Jason Conroy Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 02 Jan 2021 14:54: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: Leo Prikler Received: via spool by 45571-submit@debbugs.gnu.org id=B45571.16095992242809 (code B ref 45571); Sat, 02 Jan 2021 14:54:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 14:53:44 +0000 Received: from localhost ([127.0.0.1]:59603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviHo-0000jE-0s for submit@debbugs.gnu.org; Sat, 02 Jan 2021 09:53:44 -0500 Received: from mail-ej1-f41.google.com ([209.85.218.41]:39318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kviHm-0000j0-07 for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 09:53:42 -0500 Received: by mail-ej1-f41.google.com with SMTP id n26so30628760eju.6 for <45571@debbugs.gnu.org>; Sat, 02 Jan 2021 06:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b4adf6M3zDTcn0DAwdtgvyyy8h0dqBbol3TyFcqOC4E=; b=L6mCX8VuJRi0KS+KSlpyoWQwlU+KJqlwehp9Q4SoJASgxOe4sVs1nnihbhJCX0RBbW jxnxuN4RUUx/FEQvfkSfRKm7Ab8n5Z9wMZTMExZ+MZqerLJLjGMATCeotvicN8Pc9uDZ ij7NJODKVvMB3H4lYeE5gRqTJrSlZMztKrBni5J/ZVp4oIJJEBHqVj/zrnVCgJW6MLrK Jk9wF7T3WXjE5O4jydU+VikqMeDW3dVJmhecMgMeUeDDtlwwV3KHh4kWeF2UVHlx/S7o u+E27nQvESZEtvXWvkQosClb6L6Tm5YNWyzq3J+iP3eS2zvR2WaEWYiRNwPI88NBakze RhVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b4adf6M3zDTcn0DAwdtgvyyy8h0dqBbol3TyFcqOC4E=; b=tmhr5l0Jwqkj2jybmPZfXhTrdnMA5sWZuUOtDb1RkLaPy5aMg89+1+bnbRR1qDSdtC V+pbt9sSptjJeDg0p71ZPn2Q1bTMvvq/moaDPZGe2i4cxyo7/Dc3ytEGaJPi5vz+Slsh 35QpCQaCgqNZtZy3mtV3nss9OK4unBE5nYN8SKW/XkvHdr37kPxqMws53qdX5HpQvhhB gC8SISd4YBhPHUe8gnpuWiHH9DN50XpwY9SDqOnFHBUH6GjWFzU62AP7JzclnMKZL2vy BmnfjvQGcmIze8k/TRZDnjJiAeM1jdgjCx/2zStGVqC7xQ+6nY77uSpauaC6B4UEutVF jdow== X-Gm-Message-State: AOAM531JfX+k/Q5fFySg8uvUqH3OulVK95GadLruK2/tNi4KytddaAWX A/PNVh8W36YqRihZcw8+q+UTQVVUT0JFbv1zLU4= X-Google-Smtp-Source: ABdhPJy8P4aQ9GyGMpC2a9yfjIchD6j3Xc74OHlqMsgGcnFfKeyWDQPFc/sG+Je3qq0GW1Alaaw/YC8UKW4KbaCUKcA= X-Received: by 2002:a17:906:2f83:: with SMTP id w3mr8733371eji.292.1609599216085; Sat, 02 Jan 2021 06:53:36 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <250d033edc273b0f89e2bd37a331a3f961a8d785.camel@student.tugraz.at> From: Jason Conroy Date: Sat, 2 Jan 2021 09:52:59 -0500 Message-ID: Content-Type: multipart/alternative; boundary="000000000000816e2f05b7ec05d9" 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=gmail.com header.s=20161025 header.b=L6mCX8Vu; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (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: 2A1759402A9 X-Spam-Score: -1.23 X-Migadu-Scanner: scn1.migadu.com X-TUID: +43FDMsubc/5 --000000000000816e2f05b7ec05d9 Content-Type: text/plain; charset="UTF-8" On Sat, Jan 2, 2021 at 9:29 AM Leo Prikler 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? > > > > 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. 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. > > 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. > At > the very least, there should be syntax like > > (user-account > (inherit sane-system-account-defaults) > (name "gdm") > (id 92)) > > Perhaps there could also be a procedure (system-account+group name > #:key comment uid gid). > > Regards, > Leo > > --000000000000816e2f05b7ec05d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 2, 2021 at 9:29 AM Leo Pr= ikler <leo.prikler@stud= ent.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 <leo.prikler@student.tugraz.at> wrote:
> > >
> > > > > And it indeed is possible to add (uid 4711) in the= literal
> > and it
> > > > > will work
> > > > > just fine.=C2=A0
> > > > I'm aware you're joking, or at least I hope you= are,
> > >
> > > What?=C2=A0 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<= br> > 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.=C2=A0 As far as development is concerned,<= br> one could add a check to see, that no conflicts exist between services
extending account-service-type.

Assuming tha= t authors of new services tend to choose the lowest free ID, is this valida= tion sufficient to ensure that two services checked around the same time by= different authors won't collide?
= =C2=A0
> > From the solutions we do have so far, I believe that making user<= br> > > accounts an explicit part of service configuration (in what shape=
> > may
> > still be up for debate), with reasonable defaults including numer= ic
> > UIDs and GIDs (at least) for essential services such as GDM sound= s
> > like
> > the best option.=C2=A0 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 tha= t
> support for custom UIDs/GIDs remains consistent across services.
<= /blockquote>
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.=C2=A0 <= /blockquote>

Leo, I'm not sure what you mean by updating = two fields. Are you saying that some services already permit manual selecti= on of UIDs? I was proposing setting that value in the "users" sec= tion of operating-system (or elsewhere) rather than setting it in the "= ;services" section, but not both places.

Since Guix already uses a central a= llocator for UIDs and GIDs (implemented using simple counters), I was imagi= ning 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 s= imilar name-to-ID mapping in operating-system where users specify their ove= rrides.
=C2=A0
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.=C2=A0 =

The thought of making other parts of the a= ccount configurable occurred to me, but I couldn't come up with any ser= ious use cases either.
=C2=A0
At
the very least, there should be syntax like

(user-account
=C2=A0(inherit sane-system-account-defaults)
=C2=A0(name "gdm")
=C2=A0(id 92))

Perhaps there could also be a procedure (system-account+group name
#:key comment uid gid).

Regards,
Leo

--000000000000816e2f05b7ec05d9--