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 WAuhMsx+8F9PNwAA0tVLHw (envelope-from ) for ; Sat, 02 Jan 2021 14:10:20 +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 8HldLsx+8F+VVQAAbx9fmQ (envelope-from ) for ; Sat, 02 Jan 2021 14:10:20 +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 30899940149 for ; Sat, 2 Jan 2021 14:10:20 +0000 (UTC) Received: from localhost ([::1]:58114 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvhbm-0003J7-10 for larch@yhetil.org; Sat, 02 Jan 2021 09:10:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvhbX-0003Iu-4O for bug-guix@gnu.org; Sat, 02 Jan 2021 09:10:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:47456) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kvhbW-0001V5-Th for bug-guix@gnu.org; Sat, 02 Jan 2021 09:10:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kvhbW-0007T3-Ny for bug-guix@gnu.org; Sat, 02 Jan 2021 09:10: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:10: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.160959655828409 (code B ref 45571); Sat, 02 Jan 2021 14:10:02 +0000 Received: (at 45571) by debbugs.gnu.org; 2 Jan 2021 14:09:18 +0000 Received: from localhost ([127.0.0.1]:58958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvhan-0007O6-Q0 for submit@debbugs.gnu.org; Sat, 02 Jan 2021 09:09:18 -0500 Received: from mail-ed1-f51.google.com ([209.85.208.51]:43698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kvhal-0007Ne-Al for 45571@debbugs.gnu.org; Sat, 02 Jan 2021 09:09:16 -0500 Received: by mail-ed1-f51.google.com with SMTP id y24so22214950edt.10 for <45571@debbugs.gnu.org>; Sat, 02 Jan 2021 06:09:15 -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=625isnM4ljgWeHv3hSqIywHam0mk+OMf03WXeB5W/8U=; b=XB9BQHk7VljRSHYhgaa62AqAtmVWOJR14FrQYv/PCB74FZt5DnN5Nf1g+RjihNuuNk bqUbzOIOhN2+kDtThtttSJ6pBfpxBRHt8K7fnl5nqJ+OXwwZmqd2HFCrqp9869NhXAJM fhczrIX4jFj1bx+hZe7INQg2Bbr0ID6GRTARrK0bVBbBzuF6OwsyPUQ5dnW/Mx4o4XrX 3JIlTu/me2CHr6GImjo5xg1wWAr4cOYorQRj4wGCIiSkwyGGl5rOWfAvxyNd4cVF1t4C IwJAQQ4z9WlHDDTYDNIId4XLyHh20vjxAg5AQyr0TBXj89mt1ZQDbwc5JdFpCsJDjd8B DcUA== 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=625isnM4ljgWeHv3hSqIywHam0mk+OMf03WXeB5W/8U=; b=Mq+YmsodxjzaSxCWRj9seSYotM/+LRLsWO4GP7ak8qRwMPIbHZJi0Q2+bLf77rg1o3 hqmszQGr9sfrd14m1eG+sfv6SN8fSvK8z9HWRLTomMxKsf6J7qlVrl2FMS6TJ3m97J0y NOBoNlridG3O1CNfJyhOhUpum/UNlww1UiobFJKDGh0JuTbb3Bm0iE4enFLCpGYV58U9 51ENik0/a6+T9Fhx9y4NsW67TY4R9n0adKiYaiZYU92PwzZb6YhhjKQBN+rhm2VwuwpZ sib8mfiJaWtBawX+ho3Ifh+hL4jMqmzMS3/9IIZd//vqAI5EOU5lPh/Q225Urw71qOr1 yvkw== X-Gm-Message-State: AOAM533dQWi3bKs4PM1+/gmtq3+wwTUp550b2k7YZBtqfdwBfGS0Mwq6 4DsjWj6Ilf6hMLJ4HcK0RGBa4Q3/RJSFeTuR8czQhRGl X-Google-Smtp-Source: ABdhPJyfQJbxB8+EWk+p2a2m4SuHmiGmQ3R5NNiQatIYsrJXoMJi+bRp9+Nm/us3vgrhwHdL94iw0ERsT+xnTGNZASw= X-Received: by 2002:aa7:d916:: with SMTP id a22mr63043757edr.122.1609596174358; Sat, 02 Jan 2021 06:02:54 -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> In-Reply-To: <0d5ecae08ad352669fab46858eeefff7f6446998.camel@student.tugraz.at> From: Jason Conroy Date: Sat, 2 Jan 2021 09:02:18 -0500 Message-ID: Content-Type: multipart/alternative; boundary="000000000000345b2805b7eb50e5" 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=XB9BQHk7; 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: 30899940149 X-Spam-Score: -1.23 X-Migadu-Scanner: scn0.migadu.com X-TUID: Yjuu36ddDuO/ --000000000000345b2805b7eb50e5 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 1, 2021 at 10:11 PM Leo Prikler 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. >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. --000000000000345b2805b7eb50e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 1, 2021 at 10:11 PM Leo P= rikler <leo.prikler@stu= dent.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 a= nd 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 s= table
> system
> user ids.

My reaction to this was not t= hat defaults are bad, but that dispersing numeric literals throughout the c= ode is. Collectively these values specify the contents of a registry, so th= at registry might as well be located centrally. Or at least, there should b= e some mechanism to ensure that two services can't claim the same defau= lt ID, otherwise the collision will not manifest until somebody instantiate= s a system with the colliding services.

>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.=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 that support for custom UIDs/GIDs remains cons= istent across services.
--000000000000345b2805b7eb50e5--