GNU logs - #36508, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#36508: GDM files have incorrect owner after temporarily replacing with SDDM
Resent-From: ison <ison@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 05 Jul 2019 08:37:01 +0000
Resent-Message-ID: <handler.36508.B.156231579617712 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 36508 <at> debbugs.gnu.org
Date: Fri, 5 Jul 2019 02:36:21 -0600
From: ison <ison@HIDDEN>
Message-ID: <20190705083620.lbzu7a33awbymh3d@cf0>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: NeoMutt/20180716
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

After replacing GDM with SDDM in my Guix System config (to test Wayland) and
then reverting back to my old config and reconfiguring GDM would crash
(printing out around 500 lines about creating a seat)
I also tried rolling back to the generation I had before using SDDM and it would
still crash.
In both instances I also tried "herd restart xorg-server" but same problem.

I then checked the log file /var/log/gdm/greeter.log which had errors such as:
-------------------
Fatal server error:
(EE) Cannot open log file "/var/lib/gdm/.local/share/xorg/Xorg.pid-720.log"
-------------------

And then I could verify that files inside of /var/lib/gdm had incorrect
ownership of 9##:gdm
where 9## was some 3-digit number I can't remember now.
(note: the directory itself /var/lib/gdm still had correct ownership gdm:gdm)

I then manually fixed the ownership with:
chown -R gdm:gdm /var/lib/gdm
and GDM successfully came up without crashing.

The relevant portion of my config when I replaced GDM with SDDM was:
-------------------------------
(operating-system
  ...
  (services
    (cons*
      ...
      (sddm-service
        (sddm-configuration
          (display-server "wayland")))

      ;; Return %desktop-services with GDM removed
      (remove (lambda (service)
                (eq? (service-kind service) gdm-service-type))
              %desktop-services))))
-------------------------------

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: ison <ison@HIDDEN>
Subject: bug#36508: Acknowledgement (GDM files have incorrect owner after
 temporarily replacing with SDDM)
Message-ID: <handler.36508.B.156231579617712.ack <at> debbugs.gnu.org>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
X-Gnu-PR-Message: ack 36508
X-Gnu-PR-Package: guix
Reply-To: 36508 <at> debbugs.gnu.org
Date: Fri, 05 Jul 2019 08:37:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 36508 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
36508: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D36508
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
References: <20190705083620.lbzu7a33awbymh3d@cf0>
In-Reply-To: <20190705083620.lbzu7a33awbymh3d@cf0>
Resent-From: Brendan Tildesley <btild@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Tue, 13 Apr 2021 13:25:02 +0000
Resent-Message-ID: <handler.36508.B36508.161832029016039 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "36508 <at> debbugs.gnu.org" <36508 <at> debbugs.gnu.org>
Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Date: Tue, 13 Apr 2021 15:24:35 +0200 (CEST)
From: Brendan Tildesley <btild@HIDDEN>
Message-ID: <1576552162.14721.1618320275616@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; 
 boundary="----=_Part_14719_1225470587.1618320275370"
Importance: Normal
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

------=_Part_14719_1225470587.1618320275370
Content-Type: multipart/alternative; 
	boundary="----=_Part_14720_877439344.1618320275371"

------=_Part_14720_877439344.1618320275371
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

I recently encountered what is likely the same bug. The directory /var/lib/gdm
had the correct permissions gdm:gdm, but all the files inside had something like
973:gdm

a43e9157ef479e94c19951cc9d228cf153bf78ee is supposed to fix this (duplicate bug
37423) but it only checks the permissions of /var/lib/gdm/ itself. Not all of
the files in it. This explains why in my case it failed to fix the permissions,
because the directory was gdm:gdm. How it got that way I don't know, and infact
it doesn't really matter. The directory is mutable, and thus can theoretically be
changed for any number of reasons. Therefore if we wish for Guix to be robust
with it's Functional design, and have meaningful rollbacks, we perhaps have no
choice but to assert the required invariants like these on mutable files.

A better solution may be to make it fully chown -R on reconfigure, but not each time
on boot?

I've attached an untested patch with a suggested solution of making
%gdm-activation operate every single time, instead of just after checking
/var/lib/gdm.



------=_Part_14720_877439344.1618320275371
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div style="" class="default-style">
   I recently encountered what is likely the same bug. The directory /var/lib/gdm
   <br>had the correct permissions gdm:gdm, but all the files inside had something like
   <br>973:gdm
   <br>
   <br>a43e9157ef479e94c19951cc9d228cf153bf78ee is supposed to fix this (duplicate bug
   <br>37423) but it only checks the permissions of /var/lib/gdm/ itself. Not all of
   <br>the files in it. This explains why in my case it failed to fix the permissions,
   <br>because the directory was gdm:gdm. How it got that way I don't know, and infact 
  </div>
  <div style="" class="default-style">
   it doesn't really matter. The directory is mutable, and thus can theoretically be
  </div>
  <div style="" class="default-style">
   changed for any number of reasons. Therefore if we wish for Guix to be robust
  </div>
  <div style="" class="default-style">
   with it's Functional design, and have meaningful rollbacks, we perhaps have no 
  </div>
  <div style="" class="default-style">
   choice but to assert the required invariants like these on mutable files.
  </div>
  <div style="" class="default-style">
   <br>
  </div>
  <div style="" class="default-style">
   A better solution may be to make it fully chown -R on reconfigure, but not each time
  </div>
  <div style="" class="default-style">
   on boot?
   <br>
   <br>I've attached an untested patch with a suggested solution of making
   <br>%gdm-activation operate every single time, instead of just after checking
   <br>/var/lib/gdm.
   <br>
   <br>
   <br>
  </div>
 </body>
</html>
------=_Part_14720_877439344.1618320275371--

------=_Part_14719_1225470587.1618320275370
Content-Type: text/x-patch; charset=ISO-8859-1;
 name=0001-services-gdm-Correctly-set-ownership-on-var-lib-gdm.patch
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename=0001-services-gdm-Correctly-set-ownership-on-var-lib-gdm.patch
X-Part-Id: c69ffe53ac4e4a34a93d63e62b794a98

RnJvbSAzMWNiNmRiZDc1NmFmNjk1YmQ2YTFmNGQ0Yzg5YjQyMzY3YjEzMzA3IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBCcmVuZGFuIFRpbGRlc2xleSA8bWFpbEBicmVuZGFuLnNjb3Q+
CkRhdGU6IFR1ZSwgMTMgQXByIDIwMjEgMjM6MDQ6MjggKzEwMDAKU3ViamVjdDogW1BBVENIXSBz
ZXJ2aWNlczogZ2RtOiBDb3JyZWN0bHkgc2V0IG93bmVyc2hpcCBvbiAvdmFyL2xpYi9nZG0uCgoq
IGdudS9zZXJ2aWNlcy94b3JnLnNjbSAoJWdkbS1hY3RpdmF0aW9uKTogQWx3YXlzIGNob3duIC92
YXIvbGliL2dkbSwKaW5zdGVhZCBvZiBvbmx5IHdoZW4gaXQgYXBwZWFycyB0byBiZSBjb3JyZWN0
LCBiZWNhdXNlIGl0J3Mgc3RpbGwKcG9zc2libGUgdGhlIGZpbGVzIGluc2lkZSBjb3VsZCBiZSB3
cm9uZyBhbmQgYnJlYWsgR0RNLiBJIGVuY291bnRlcmVkCnRoaXMgb25jZTogaHR0cHM6Ly9pc3N1
ZXMuZ3VpeC5nbnUub3JnLzM2NTA4IC4KClBlcmhhcHMgaXQgaXMgd2l0aCBnb29kIGludGVudGlv
bnMgdG8gdHJ5IG5vdCBydW5uaW5nIHRoaXMgY29kZSBldmVyeQpzaW5nbGUgdGltZSBvbiBib290
LCBidXQgd2hlbiBpdCBmYWlscywgdGhlIGNvbnNlcXVlbmNlIGlzIHRoYXQgR0RNIGNhbgpicmVh
ayBub3QganVzdCBmb3IgdGhlIGN1cnJlbnQgcmV2aXNpb24sIGJ1dCBhbGwgcHJldmlvdXMgcm9s
bGJhY2sKc3lzdGVtcyBpbiBHUlVCIHdpbGwgZmFpbCwgYW5kIHN1YnNlcXVlbnQgcmVjb25maWd1
cmUtaW5ncyBmYWlsCnRvby4gVGhhdCB0b3RhbGx5IGRlc3Ryb3lzIGEgZGVza3RvcCBzeXN0ZW0g
YW5kIG91ciByb2xsYmFjawpmdW5jdGlvbmFsbHksIHdoaWNoIGlzIG11Y2ggbXVjaCB3b3JzZSEK
LS0tCiBnbnUvc2VydmljZXMveG9yZy5zY20gfCAxNSArKysrKy0tLS0tLS0tLS0KIDEgZmlsZSBj
aGFuZ2VkLCA1IGluc2VydGlvbnMoKyksIDEwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2du
dS9zZXJ2aWNlcy94b3JnLnNjbSBiL2dudS9zZXJ2aWNlcy94b3JnLnNjbQppbmRleCAxN2Q5ODNm
ZjhkLi5hMjA2YzdjOTNhIDEwMDY0NAotLS0gYS9nbnUvc2VydmljZXMveG9yZy5zY20KKysrIGIv
Z251L3NlcnZpY2VzL3hvcmcuc2NtCkBAIC04NjEsMTYgKzg2MSwxMSBAQCB0aGUgR05PTUUgZGVz
a3RvcCBlbnZpcm9ubWVudC4iKQogCiAgICAgICAgIChsZXQqICgoZ2RtIChnZXRwd25hbSAiZ2Rt
IikpCiAgICAgICAgICAgICAgICAodWlkIChwYXNzd2Q6dWlkIGdkbSkpCi0gICAgICAgICAgICAg
ICAoZ2lkIChwYXNzd2Q6Z2lkIGdkbSkpCi0gICAgICAgICAgICAgICAoc3QgIChzdGF0ICIvdmFy
L2xpYi9nZG0iICNmKSkpCi0gICAgICAgICAgOzsgUmVjdXJzZSBpbnRvIC92YXIvbGliL2dkbSBv
bmx5IGlmIGl0IGhhcyB3cm9uZyBvd25lcnNoaXAuCi0gICAgICAgICAgKHdoZW4gKGFuZCBzdAot
ICAgICAgICAgICAgICAgICAgICAgKG9yIChub3QgKD0gdWlkIChzdGF0OnVpZCBzdCkpKQotICAg
ICAgICAgICAgICAgICAgICAgICAgIChub3QgKD0gZ2lkIChzdGF0OmdpZCBzdCkpKSkpCi0gICAg
ICAgICAgICAoZm9yLWVhY2ggKGxhbWJkYSAoZmlsZSkKLSAgICAgICAgICAgICAgICAgICAgICAg
IChjaG93biBmaWxlIHVpZCBnaWQpKQotICAgICAgICAgICAgICAgICAgICAgIChmaW5kLWZpbGVz
ICIvdmFyL2xpYi9nZG0iCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIzpkaXJl
Y3Rvcmllcz8gI3QpKSkpKSkpCisgICAgICAgICAgICAgICAoZ2lkIChwYXNzd2Q6Z2lkIGdkbSkp
KQorICAgICAgICAgIChmb3ItZWFjaCAobGFtYmRhIChmaWxlKQorICAgICAgICAgICAgICAgICAg
ICAgIChjaG93biBmaWxlIHVpZCBnaWQpKQorICAgICAgICAgICAgICAgICAgICAoZmluZC1maWxl
cyAiL3Zhci9saWIvZ2RtIgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjOmRpcmVj
dG9yaWVzPyAjdCkpKSkpKQogCiAoZGVmaW5lIGRidXMtZGFlbW9uLXdyYXBwZXIKICAgKHByb2dy
YW0tZmlsZQotLSAKMi4zMS4xCgo=
------=_Part_14719_1225470587.1618320275370--

Message sent to bug-guix@HIDDEN:

Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Tue, 13 Apr 2021 20:54:01 +0000
Resent-Message-ID: <handler.36508.B36508.161834720411220 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
From: Mark H Weaver <mhw@HIDDEN>
In-Reply-To: <1576552162.14721.1618320275616@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
Date: Tue, 13 Apr 2021 16:51:35 -0400
Message-ID: <87czuxsya5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi Brendan,

Brendan Tildesley via Bug reports for GNU Guix <bug-guix@HIDDEN>
writes:

> I recently encountered what is likely the same bug. The directory /var/lib/gdm
> had the correct permissions gdm:gdm, but all the files inside had something like
> 973:gdm

The underlying problem here, which I've also experienced, is that if you
reconfigure your system with fewer users/groups, and then later add
those users/groups back, there is no guarantee that they will be
assigned the same UIDs and GIDs.

This problem is made much worse by the fact that files may be left
around, e.g. in /var, with the old UIDs and GIDs.

In your case, I guess that the 'gdm' user was previously assigned UID
973, but now it has been given a different UID.

In my case, after reconfiguring to a minimal system and later switching
back to a full GNOME-based desktop system, I found that many files and
directories in /var had the wrong owner or group.  Here's what I saw
before I cleaned things up:

--8<---------------cut here---------------start------------->8---
root@jojen ~# ls -l /var/lib/
total 4
drwxr-xr-x 1 colord colord    40 Mar 28  2017 colord
drwx------ 1 995    978       56 Sep  3 02:10 gdm
drwx------ 1 root   root   30400 Dec 25 01:55 NetworkManager
-rw------- 1 root   root     512 Dec 25 01:35 random-seed
drwxr-xr-x 1 colord colord   164 Dec 28  2017 sddm
drwx------ 1 tor    tor      178 Dec 19 21:28 tor
drwx------ 1 root   root      20 Sep  5 01:32 udisks2
drwxr-xr-x 1 root   root     274 Dec 25 01:55 upower
drwxr-xr-x 1 root   root      86 Mar 28  2017 wicd
root@jojen ~# ls -la /var/lib/gdm/
total 4
drwx------ 1  995    978  56 Sep  3 02:10 .
drwxr-xr-x 1 root root   750 Dec 25 01:59 ..
drwxr-xr-x 1  994 colord  64 Sep  3 02:10 .cache
drwx------ 1  994 colord  54 Sep  3 02:10 .config
-rw------- 1  994 colord  16 Sep  3 02:10 .esd_auth
drwxr-xr-x 1  994 colord  10 Sep  3 02:10 .local
root@jojen ~# 
--8<---------------cut here---------------end--------------->8---

Given the fact that existing files and directories in /var can
*effectively* have their ownership changed, I think that this issue
could be a security risk.

There's some discussion of this issue at <https://bugs.gnu.org/44944>,
although I'm not sure that Danny's suggested solution is practical.

Here's one idea: when activating a system, *never* delete users or
groups if files still exist that are owned by those users/groups.
Checking all filesystems would likely be too expensive, but perhaps it
would be sufficient to check certain directories such as /var, /etc, and
possibly the top directory of /home.

What do you think?

      Mark

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Brendan Tildesley <btild@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 14 Apr 2021 04:33:01 +0000
Resent-Message-ID: <handler.36508.B36508.161837472731380 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: 36508 <at> debbugs.gnu.org
Cc: Mark H Weaver <mhw@HIDDEN>, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.161837472731380
          (code B ref 36508); Wed, 14 Apr 2021 04:33:01 +0000
Received: (at 36508) by debbugs.gnu.org; 14 Apr 2021 04:32:07 +0000
Received: from localhost ([127.0.0.1]:33119 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lWXCB-0008A4-8p
	for submit <at> debbugs.gnu.org; Wed, 14 Apr 2021 00:32:07 -0400
Received: from mout-p-102.mailbox.org ([80.241.56.152]:15662)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <btild@HIDDEN>) id 1lWXC9-00089V-1j
 for 36508 <at> debbugs.gnu.org; Wed, 14 Apr 2021 00:32:06 -0400
Received: from smtp1.mailbox.org (smtp1.mailbox.org
 [IPv6:2001:67c:2050:105:465:1:1:0])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4FKqLk5FWMzQk1B;
 Wed, 14 Apr 2021 06:31:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h=
 content-transfer-encoding:content-type:content-type:mime-version
 :subject:subject:references:in-reply-to:message-id:from:from
 :date:date:received; s=mail20150812; t=1618374714; bh=ouPL1qs6om
 xiQMs7gkF+Ue3RkqqmKGDxWSkqSIO7ZNQ=; b=eAp9VdEkykKOE+HGfgoKQBjJhx
 yryIWbJ1CtU6hG9hIAsb93f/z8RRllTxiP90gTGu81zyNPiAbixre2toJBdudC5A
 3Lcvl9QPSmFJZbhjGgvyuWpm5KftRF+bof4C18tapXnbMKE04B4sX0dj+7Bn4IO2
 2IE+2CAe/2YoLHfgbFyGXJFeI9L3d0cIZPhA6jJB4828rZSPimQftcKghTpklgXf
 XqGPBAFe6f5Av10CCe7pAQ8iffyoubgDvlciC8x4xYrk43FyIflvB7myuFs9J3O4
 Rxrke7p2NlGZ9Vy5ItX2AK0Bl18F5N84TLmqYViLpcP4INqHyKrvbDMgsrwQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org;
 s=mail20150812; t=1618374716;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=C62iV6IxQGLQIxbZx1DNdC1AUs0Vor4kHPo/eDxfr2M=;
 b=XGv7labxwrvcBCvki7nr1izMqCQMd1JxqjqEmfPSMSXirRGd6+74NGoKdY09bkDhwgEoyM
 0u++AkanPW/qQK6/uKLvlQtMzNV+cgoYWzGcQ4ll8yMXIjZw4Dmind4mUb/iKr7AjXjcMF
 frMhzB2AsNZwdHc8oJGHXaPJufOzaLwfNEyrbcWeTnjpWNTTZlJlycta51yhxLyXkikwTJ
 uWZN/zyXuQyouYdajTcS/3DcROF/hKp5O+hBwJt7Bv5iEli4dZMZIkOK/RAgVT+Fyzw3tL
 VjeuLMfOQtx3fki8jhLAZYzFTCTa98p8GFmOUyNik3dPj6tw99LxapSCOFa5IQ==
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240])
 by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de
 [80.241.56.122]) (amavisd-new, port 10030)
 with ESMTP id fyRO9kQPTyV9; Wed, 14 Apr 2021 06:31:54 +0200 (CEST)
Date: Wed, 14 Apr 2021 06:31:54 +0200 (CEST)
From: Brendan Tildesley <btild@HIDDEN>
Message-ID: <461701204.22088.1618374714507@HIDDEN>
In-Reply-To: <87czuxsya5.fsf@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-MBO-SPAM-Probability: 
X-Rspamd-Score: -6.44 / 15.00 / 15.00
X-Rspamd-Queue-Id: 5CDF017CC
X-Rspamd-UID: 553017
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)


> On 04/13/2021 10:51 PM Mark H Weaver <mhw@HIDDEN> wrote:
> 
>  
> Hi Brendan,
> 
> Brendan Tildesley via Bug reports for GNU Guix <bug-guix@HIDDEN>
> writes:
> 
> > I recently encountered what is likely the same bug. The directory /var/lib/gdm
> > had the correct permissions gdm:gdm, but all the files inside had something like
> > 973:gdm
> 
> The underlying problem here, which I've also experienced, is that if you
> reconfigure your system with fewer users/groups, and then later add
> those users/groups back, there is no guarantee that they will be
> assigned the same UIDs and GIDs.
> 
> This problem is made much worse by the fact that files may be left
> around, e.g. in /var, with the old UIDs and GIDs.
> 
> In your case, I guess that the 'gdm' user was previously assigned UID
> 973, but now it has been given a different UID.
> 
> In my case, after reconfiguring to a minimal system and later switching
> back to a full GNOME-based desktop system, I found that many files and
> directories in /var had the wrong owner or group.  Here's what I saw
> before I cleaned things up:
> 
> --8<---------------cut here---------------start------------->8---
> root@jojen ~# ls -l /var/lib/
> total 4
> drwxr-xr-x 1 colord colord    40 Mar 28  2017 colord
> drwx------ 1 995    978       56 Sep  3 02:10 gdm
> drwx------ 1 root   root   30400 Dec 25 01:55 NetworkManager
> -rw------- 1 root   root     512 Dec 25 01:35 random-seed
> drwxr-xr-x 1 colord colord   164 Dec 28  2017 sddm
> drwx------ 1 tor    tor      178 Dec 19 21:28 tor
> drwx------ 1 root   root      20 Sep  5 01:32 udisks2
> drwxr-xr-x 1 root   root     274 Dec 25 01:55 upower
> drwxr-xr-x 1 root   root      86 Mar 28  2017 wicd
> root@jojen ~# ls -la /var/lib/gdm/
> total 4
> drwx------ 1  995    978  56 Sep  3 02:10 .
> drwxr-xr-x 1 root root   750 Dec 25 01:59 ..
> drwxr-xr-x 1  994 colord  64 Sep  3 02:10 .cache
> drwx------ 1  994 colord  54 Sep  3 02:10 .config
> -rw------- 1  994 colord  16 Sep  3 02:10 .esd_auth
> drwxr-xr-x 1  994 colord  10 Sep  3 02:10 .local
> root@jojen ~# 
> --8<---------------cut here---------------end--------------->8---
> 
> Given the fact that existing files and directories in /var can
> *effectively* have their ownership changed, I think that this issue
> could be a security risk.

Yes and they could change for any reason under the sun, and so we have no
choice but to set them right on service activation.

Guix system rollbacks should be a supported feature of Guix, not just a gimmick
that falls out of its design. It should be that a Guix user could leave their
system for 5 years, and then do a guix pull; guix system reconfigure in the year
2026. Perhaps at that time the new system will break, and then its desirable
that they can rollback to the previous generation. So what fixes we put in to 
Guix services today need to consider not just how files could have changed in
the past, but how they might change in breaking ways in the future, within reason.
I don't know off the top of my head of any way that can be done other than to
have chmod -R gdm:gdm /var/lib/gdm always executed.
> 
> There's some discussion of this issue at <https://bugs.gnu.org/44944>,
> although I'm not sure that Danny's suggested solution is practical.
> 
> Here's one idea: when activating a system, *never* delete users or
> groups if files still exist that are owned by those users/groups.
> Checking all filesystems would likely be too expensive, but perhaps it
> would be sufficient to check certain directories such as /var, /etc, and
> possibly the top directory of /home.
> 
> What do you think

Wouldn't that imply that uids could be randomly different on different systems
with the same configuration, and then remain statically different permanently?
We want as little randomness and moving parts as possible. It's yet another
way the system is not actually Functional, but has state.

Seems this bug spans 3 or so different bug reports. In http://issues.guix.gnu.org/45571
I commented that Nix uses hard coded id's, sorta like how ports are allocated
for a purpose:

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix

Perhaps you are thinking of other kinds of security issues that could be caused that
I'm not thinking of. In that case maybe Nix devs have already made the best choice by
making them static?

... After all, if the permissions can change, then it is possible another user could
actually modify the contents of /var/lib/gdm its self, thereby infecting other users,
if for some reason that other malicious user gets allocated that ID.
That further points towards static ID's like Nix has as a solution.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 14 Apr 2021 10:33:02 +0000
Resent-Message-ID: <handler.36508.B36508.16183963793603 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.16183963793603
          (code B ref 36508); Wed, 14 Apr 2021 10:33:02 +0000
Received: (at 36508) by debbugs.gnu.org; 14 Apr 2021 10:32:59 +0000
Received: from localhost ([127.0.0.1]:33669 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lWcpP-0000w2-EF
	for submit <at> debbugs.gnu.org; Wed, 14 Apr 2021 06:32:59 -0400
Received: from eggs.gnu.org ([209.51.188.92]:43136)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1lWcpN-0000vp-F2
 for 36508 <at> debbugs.gnu.org; Wed, 14 Apr 2021 06:32:57 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:40035)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <ludo@HIDDEN>)
 id 1lWcpG-0007E9-Nq; Wed, 14 Apr 2021 06:32:51 -0400
Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=34782 helo=ribbon)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <ludo@HIDDEN>)
 id 1lWcpG-0000TX-9X; Wed, 14 Apr 2021 06:32:50 -0400
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN>
X-URL: http://www.fdn.fr/~lcourtes/
X-Revolutionary-Date: 25 Germinal an 229 de la =?UTF-8?Q?R=C3=A9volution?=
X-PGP-Key-ID: 0x090B11993D9AEBB5
X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
Date: Wed, 14 Apr 2021 12:32:48 +0200
In-Reply-To: <87czuxsya5.fsf@HIDDEN> (Mark H. Weaver's message of "Tue, 13
 Apr 2021 16:51:35 -0400")
Message-ID: <875z0pgnqn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi Mark,

Mark H Weaver <mhw@HIDDEN> skribis:

> Brendan Tildesley via Bug reports for GNU Guix <bug-guix@HIDDEN>
> writes:
>
>> I recently encountered what is likely the same bug. The directory /var/l=
ib/gdm
>> had the correct permissions gdm:gdm, but all the files inside had someth=
ing like
>> 973:gdm
>
> The underlying problem here, which I've also experienced, is that if you
> reconfigure your system with fewer users/groups, and then later add
> those users/groups back, there is no guarantee that they will be
> assigned the same UIDs and GIDs.

Yes.

The patch Brendan posted LGTM (though I=E2=80=99m surprised the directory i=
tself
can have the right UID/GID while files inside it don=E2=80=99t; perhaps thi=
s was
made possible by 2161820ebbbab62a5ce76c9101ebaec54dc61586, which chowns
the home directory unconditionally.)

Note that there are other places, in addition to GDM, where we
forcefully reset the UID/GID of the home directory (e.g., for the
=E2=80=98knot-resolver=E2=80=99 service.)

My preferred solution to this would be to unconditionally chown -R home
directories upon activation (for efficiency, it would be best if we
could do that if and only if the home directory itself has wrong
ownership).  Thoughts?

systemd-homed does something like that.  The intuition here is that
UIDs/GIDs are implementation details that should get out of the way.

> There's some discussion of this issue at <https://bugs.gnu.org/44944>,
> although I'm not sure that Danny's suggested solution is practical.
>
> Here's one idea: when activating a system, *never* delete users or
> groups if files still exist that are owned by those users/groups.
> Checking all filesystems would likely be too expensive, but perhaps it
> would be sufficient to check certain directories such as /var, /etc, and
> possibly the top directory of /home.

How would you determine which directories to look at though?  What if we
miss an important one?

Note that the ID allocation strategy in (gnu build accounts) ensures
UIDs/GIDs aren=E2=80=99t reused right away (same strategy as implemented by
Shadow, etc.).  So if you remove =E2=80=9Cbob=E2=80=9D, then add =E2=80=9Ca=
lice=E2=80=9D, =E2=80=9Calice=E2=80=9D won=E2=80=99t
be able to access the left-behind /home/bob because it has a different
UID.

Ludo=E2=80=99.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Brendan Tildesley <btild@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Wed, 14 Apr 2021 12:22:02 +0000
Resent-Message-ID: <handler.36508.B36508.161840287922894 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: 36508 <at> debbugs.gnu.org
Cc: Mark H Weaver <mhw@HIDDEN>, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.161840287922894
          (code B ref 36508); Wed, 14 Apr 2021 12:22:02 +0000
Received: (at 36508) by debbugs.gnu.org; 14 Apr 2021 12:21:19 +0000
Received: from localhost ([127.0.0.1]:33860 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lWeWE-0005xC-SE
	for submit <at> debbugs.gnu.org; Wed, 14 Apr 2021 08:21:19 -0400
Received: from mout-p-101.mailbox.org ([80.241.56.151]:24040)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <btild@HIDDEN>) id 1lWeWC-0005wu-MG
 for 36508 <at> debbugs.gnu.org; Wed, 14 Apr 2021 08:21:18 -0400
Received: from smtp1.mailbox.org (smtp1.mailbox.org
 [IPv6:2001:67c:2050:105:465:1:1:0])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4FL1m6653DzQjwf;
 Wed, 14 Apr 2021 14:21:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h=
 content-transfer-encoding:content-type:content-type:mime-version
 :subject:subject:references:in-reply-to:message-id:from:from
 :date:date:received; s=mail20150812; t=1618402864; bh=us9OXY5O5p
 GpfHLemJ5PLTjoywNrQkvn+AAnhigvAzs=; b=VAECrUpRBWVeYUy/WTvdZ/sEZm
 R4kkZqXlUhHtVc+0HgfFpcA4pwn0+7qVMMKqUFdZhz7L5DOAAAe+TiojnoXuFJTv
 Xzy6v1Sz7Sm4LVvQG78qke11RQSSacWSAzsWQRYCt9IjCsyJ3Ngk079wRmRKqAmP
 q1g7X/lJVdLwoG+BXlxfmGpsHiCUc2tL1YJl1wc6ASMbJMNMZu/emrcf/7tNcJZ4
 MuU5a27wPP9Kuuabw/4GqwXb3T7wYhZ8D4tzpRQPAF88btP7bROrzqC33pz8mQ4W
 5myz7WjjIeuCIBSco5zb2vWPiyjp16xqXqyUcYvakhwkHSzidjz9/EBktcpQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org;
 s=mail20150812; t=1618402869;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding:
 in-reply-to:in-reply-to:references:references;
 bh=q69mD9LGTrkxrzfmEZzwft414MS47zJTwr+PDEiit4Q=;
 b=fEZkH2tKz68kdsWqzjpg/f2305CvzkAlyGvpH5E9Gq8+qXO/ZhhARB8CKWtXPJHyBBJ9x4
 Ii9BD6Yy8acxvonXm9jbP8+CxLUrwxws7GufuqxE5Eyw6XsqdpvnfvWv2h6XPpuF/hLQuP
 XvB8KlXy7zUIpKevQQm0FJDNtzpkDz8tD2kNS7EIjzTWx0jqTQOp76kob+cwItv75bpe55
 icfoWhXdGWL+IIK/cfoVoBHdknOiqTLNlj+esxuklGwyUlXRIsaWLcPFLi91UgymAxg6lu
 KrwCLZs39ZrpB7Z7wezMy68/AQ0nH7FJh8ZbEDoBMzmPc1gFTv8cASihCmINSg==
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240])
 by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de
 [80.241.56.125]) (amavisd-new, port 10030)
 with ESMTP id F7lSshsIBeZ3; Wed, 14 Apr 2021 14:21:04 +0200 (CEST)
Date: Wed, 14 Apr 2021 14:21:03 +0200 (CEST)
From: Brendan Tildesley <btild@HIDDEN>
Message-ID: <262720830.30369.1618402863721@HIDDEN>
In-Reply-To: <875z0pgnqn.fsf@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Normal
X-MBO-SPAM-Probability: 
X-Rspamd-Score: -6.13 / 15.00 / 15.00
X-Rspamd-Queue-Id: BE85217CF
X-Rspamd-UID: 8bef7e
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)


> On 04/14/2021 12:32 PM Ludovic Court=C3=A8s <ludo@HIDDEN> wrote:
>=20
> =20
> Hi Mark,
>=20
> Mark H Weaver <mhw@HIDDEN> skribis:
>=20
> > Brendan Tildesley via Bug reports for GNU Guix <bug-guix@HIDDEN>
> > writes:
> >
> >> I recently encountered what is likely the same bug. The directory /var=
/lib/gdm
> >> had the correct permissions gdm:gdm, but all the files inside had some=
thing like
> >> 973:gdm
> >
> > The underlying problem here, which I've also experienced, is that if yo=
u
> > reconfigure your system with fewer users/groups, and then later add
> > those users/groups back, there is no guarantee that they will be
> > assigned the same UIDs and GIDs.
>=20
> Yes.
>=20
> The patch Brendan posted LGTM (though I=E2=80=99m surprised the directory=
 itself
> can have the right UID/GID while files inside it don=E2=80=99t; perhaps t=
his was
> made possible by 2161820ebbbab62a5ce76c9101ebaec54dc61586, which chowns
> the home directory unconditionally.)
>=20
> Note that there are other places, in addition to GDM, where we
> forcefully reset the UID/GID of the home directory (e.g., for the
> =E2=80=98knot-resolver=E2=80=99 service.)
>=20
> My preferred solution to this would be to unconditionally chown -R home
> directories upon activation (for efficiency, it would be best if we
> could do that if and only if the home directory itself has wrong
> ownership).  Thoughts?
>=20
I'm confused. It sounds like you're suggesting to add the very IF condition=
 that my
patch removes from %gdm-activation in order to fix the problem.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 Apr 2021 14:26:01 +0000
Resent-Message-ID: <handler.36508.B36508.161849670210093 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Brendan Tildesley <btild@HIDDEN>
Cc: Mark H Weaver <mhw@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.161849670210093
          (code B ref 36508); Thu, 15 Apr 2021 14:26:01 +0000
Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 14:25:02 +0000
Received: from localhost ([127.0.0.1]:38826 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lX2vW-0002cb-19
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 10:25:02 -0400
Received: from eggs.gnu.org ([209.51.188.92]:49524)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1lX2vT-0002cD-7J
 for 36508 <at> debbugs.gnu.org; Thu, 15 Apr 2021 10:25:00 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:37295)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <ludo@HIDDEN>)
 id 1lX2vN-0000ou-4j; Thu, 15 Apr 2021 10:24:53 -0400
Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=37672 helo=ribbon)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <ludo@HIDDEN>)
 id 1lX2vM-0005ij-L9; Thu, 15 Apr 2021 10:24:52 -0400
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
 <262720830.30369.1618402863721@HIDDEN>
X-URL: http://www.fdn.fr/~lcourtes/
X-Revolutionary-Date: 26 Germinal an 229 de la =?UTF-8?Q?R=C3=A9volution?=
X-PGP-Key-ID: 0x090B11993D9AEBB5
X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
Date: Thu, 15 Apr 2021 16:24:51 +0200
In-Reply-To: <262720830.30369.1618402863721@HIDDEN> (Brendan
 Tildesley's message of "Wed, 14 Apr 2021 14:21:03 +0200 (CEST)")
Message-ID: <87o8ef8w24.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi,

Brendan Tildesley <btild@HIDDEN> skribis:

>> On 04/14/2021 12:32 PM Ludovic Court=C3=A8s <ludo@HIDDEN> wrote:

[...]

>> The patch Brendan posted LGTM (though I=E2=80=99m surprised the director=
y itself
>> can have the right UID/GID while files inside it don=E2=80=99t; perhaps =
this was
>> made possible by 2161820ebbbab62a5ce76c9101ebaec54dc61586, which chowns
>> the home directory unconditionally.)
>>=20
>> Note that there are other places, in addition to GDM, where we
>> forcefully reset the UID/GID of the home directory (e.g., for the
>> =E2=80=98knot-resolver=E2=80=99 service.)
>>=20
>> My preferred solution to this would be to unconditionally chown -R home
>> directories upon activation (for efficiency, it would be best if we
>> could do that if and only if the home directory itself has wrong
>> ownership).  Thoughts?
>>=20
> I'm confused. It sounds like you're suggesting to add the very IF conditi=
on that my
> patch removes from %gdm-activation in order to fix the problem.

I=E2=80=99d like to understand why the =E2=80=98if=E2=80=99 the patch remov=
es was problematic.
I think it relates to the commit above, but that needs more
investigation.

Ludo=E2=80=99.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 Apr 2021 18:12:01 +0000
Resent-Message-ID: <handler.36508.B36508.161851027032192 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.161851027032192
          (code B ref 36508); Thu, 15 Apr 2021 18:12:01 +0000
Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 18:11:10 +0000
Received: from localhost ([127.0.0.1]:39155 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lX6SM-0008NA-4Z
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 14:11:10 -0400
Received: from world.peace.net ([64.112.178.59]:40658)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lX6SK-0008Mx-AI
 for 36508 <at> debbugs.gnu.org; Thu, 15 Apr 2021 14:11:08 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lX6SE-0006ts-3P; Thu, 15 Apr 2021 14:11:02 -0400
From: Mark H Weaver <mhw@HIDDEN>
In-Reply-To: <461701204.22088.1618374714507@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN>
 <461701204.22088.1618374714507@HIDDEN>
Date: Thu, 15 Apr 2021 14:09:17 -0400
Message-ID: <87pmyvifmf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Brendan,

Brendan Tildesley <btild@HIDDEN> writes:

> Guix system rollbacks should be a supported feature of Guix, not just a gimmick
> that falls out of its design. It should be that a Guix user could leave their
> system for 5 years, and then do a guix pull; guix system reconfigure in the year
> 2026. Perhaps at that time the new system will break, and then its desirable
> that they can rollback to the previous generation.

This sounds like a good set of goals to strive for.  I'm not sure that
Guix, on its own, will be able to achieve reliable 5-year rollback.  I
think that would require _all_ software in Guix that maintains mutable
state on disk to gracefully support downgrading to a version from 5
years earlier.

Nonetheless, Guix can certainly do its part to try to ensure that
multi-year rollbacks can work, and I agree that it's a good thing to
keep in mind.

> So what fixes we put in to 
> Guix services today need to consider not just how files could have changed in
> the past, but how they might change in breaking ways in the future, within reason.

It's a good thing to keep in mind, yes.

> I don't know off the top of my head of any way that can be done other than to
> have chmod -R gdm:gdm /var/lib/gdm always executed.

I'm not necessarily opposed to doing that, at least as a temporary
workaround for GDM, but I don't think this is a satisfactory solution to
the larger problem.  A few points:

(1) I don't think we can assume that all files owned by a given user
    will be in that user's home directory, especially for "system"
    users.

(2) I also don't think we can assume that all files in a user's home
    directory *should* be owned by that user.  Even if it's true today,
    it might not be true tomorrow.

(3) Groups don't even have home directories.

> On 04/13/2021 10:51 PM Mark H Weaver <mhw@HIDDEN> wrote:
>> 
>> There's some discussion of this issue at <https://bugs.gnu.org/44944>,
>> although I'm not sure that Danny's suggested solution is practical.
>> 
>> Here's one idea: when activating a system, *never* delete users or
>> groups if files still exist that are owned by those users/groups.
>> Checking all filesystems would likely be too expensive, but perhaps it
>> would be sufficient to check certain directories such as /var, /etc, and
>> possibly the top directory of /home.
>> 
>> What do you think
>
> Wouldn't that imply that uids could be randomly different on different systems
> with the same configuration, and then remain statically different permanently?

Yes, and I agree that it's suboptimal.

> We want as little randomness and moving parts as possible. It's yet another
> way the system is not actually Functional, but has state.

Agreed.  Danny's suggested solution (UID = hash username) is clearly the
optimal approach in many respects.  It has the nice properties above.

The practical problem I see with Danny's approach is that in order to
make hash collisions sufficiently improbable, our UIDs and GIDs would
need to be much larger than the 16 bits that is widely supported by
POSIX software.  With 16-bit UIDs, the probability of a collision would
be 1.85% with 50 users, and 7.28% with 100 users.

To adopt this approach, I think that our UIDs and GIDs would need to be
at least 31 bits.  These are the problems I see:

(1) It's unlikely that all software in Guix robustly handles such large
    UIDs/GIDs.  Desktop systems with UIDs/GIDs larger than 65533 have
    not been widely tested, as far as I know.

(2) Even with 31 bit IDs, the probability of collisions would still be
    uncomfortably high when large numbers of users are present: with 10k
    users, the probability of hash collisions would be about 2.3%.

(3) We'd need a transition plan for users' existing file systems.

(4) It would be aesthetically unpleasant for our UIDs and GIDs to be
    random-looking numbers with 10 decimal digits.

> Seems this bug spans 3 or so different bug reports. In http://issues.guix.gnu.org/45571
> I commented that Nix uses hard coded id's, sorta like how ports are allocated
> for a purpose:
>
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix
>
> Perhaps you are thinking of other kinds of security issues that could be caused that
> I'm not thinking of.

I'm not sure what you're getting at here.  The only security issue I've
raised so far is that ownership of files can _effectively_ be changed
when removing services and later adding them back.  For example, in my
case, 'colord' ended up being the owner of files in /var/lib/gdm.

> In that case maybe Nix devs have already made the best choice by
> making them static?

That might well be true.  At the present time, this is the option that
seems most appealing to me.

One possible approach would be to add a field to our 'operating-system'
record that explicitly specifies a total mapping from user/group names
to UIDs/GIDs.  It could either be a procedure (to support Danny's
hashing approach with its nice properties) or possibly also an alist for
convenience.  If any entries were missing, it would raise an error.

One risk to this approach is that users could accidentally make a mess
of their system if they made a mistake while changing that field.

What do you think?

    Thanks,
      Mark

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 Apr 2021 18:33:02 +0000
Resent-Message-ID: <handler.36508.B36508.16185115531786 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.16185115531786
          (code B ref 36508); Thu, 15 Apr 2021 18:33:02 +0000
Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 18:32:33 +0000
Received: from localhost ([127.0.0.1]:39182 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lX6n2-0000Sk-Qy
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 14:32:33 -0400
Received: from world.peace.net ([64.112.178.59]:40700)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lX6n1-0000SX-RH
 for 36508 <at> debbugs.gnu.org; Thu, 15 Apr 2021 14:32:32 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lX6mv-0008R2-6r; Thu, 15 Apr 2021 14:32:25 -0400
From: Mark H Weaver <mhw@HIDDEN>
In-Reply-To: <875z0pgnqn.fsf@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
Date: Thu, 15 Apr 2021 14:30:40 -0400
Message-ID: <87lf9jiems.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:

> Note that there are other places, in addition to GDM, where we
> forcefully reset the UID/GID of the home directory (e.g., for the
> =E2=80=98knot-resolver=E2=80=99 service.)
>
> My preferred solution to this would be to unconditionally chown -R home
> directories upon activation (for efficiency, it would be best if we
> could do that if and only if the home directory itself has wrong
> ownership).  Thoughts?

It might be okay to do this in specific cases like /var/lib/gdm, but I'm
very uncomfortable doing it for *all* users, because:

(1) We shouldn't assume that all files within a home directory are
    supposed to be owned by that user.

(2) We shouldn't assume that all files owned by a user will be within
    their home directory.

(3) We shouldn't assume that all files within a home directory are
    supposed to have the same 'group'.  I, for one, have sometimes had
    subdirectories of my home directory with a different 'group', to
    either restrict or grant other users access to selected files or
    directories.

(4) Groups do not, in general, have home directories.

(5) I consider it unsatifactory for there to be *any* window of time
    during system activation when the ownership of files is incorrect.

>> Here's one idea: when activating a system, *never* delete users or
>> groups if files still exist that are owned by those users/groups.
>> Checking all filesystems would likely be too expensive, but perhaps it
>> would be sufficient to check certain directories such as /var, /etc, and
>> possibly the top directory of /home.
>
> How would you determine which directories to look at though?  What if we
> miss an important one?

Yes, that's a good point.  I suppose that my idea above is not
satifactory either.

> Note that the ID allocation strategy in (gnu build accounts) ensures
> UIDs/GIDs aren=E2=80=99t reused right away (same strategy as implemented =
by
> Shadow, etc.).  So if you remove =E2=80=9Cbob=E2=80=9D, then add =E2=80=
=9Calice=E2=80=9D, =E2=80=9Calice=E2=80=9D won=E2=80=99t
> be able to access the left-behind /home/bob because it has a different
> UID.

This mechanism is insufficient, because it only avoids the problem if
you add "alice" at the same time that "bob" is removed.  If you remove
"bob" during one system activation, and then later add "alice", then
"alice" might well be able to access bob's left-behind files.

In the case that I personally witnessed on my Guix system, files within
/var/lib/gdm ended up with 'colord' as their group.  That's not good.

Increasingly, I'm leaning toward the idea that the complete mapping from
names to IDs should somehow be explicitly given as part of the OS
configuration, as I advocated in <https://bugs.gnu.org/36508#26>.

What do you think?

     Thanks,
       Mark

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 Apr 2021 18:38:01 +0000
Resent-Message-ID: <handler.36508.B36508.16185118292238 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.16185118292238
          (code B ref 36508); Thu, 15 Apr 2021 18:38:01 +0000
Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 18:37:09 +0000
Received: from localhost ([127.0.0.1]:39192 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lX6rU-0000a1-NV
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 14:37:08 -0400
Received: from world.peace.net ([64.112.178.59]:40712)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lX6rS-0000Z8-7w
 for 36508 <at> debbugs.gnu.org; Thu, 15 Apr 2021 14:37:07 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lX6rL-0000LE-VY; Thu, 15 Apr 2021 14:37:00 -0400
From: Mark H Weaver <mhw@HIDDEN>
In-Reply-To: <875z0pgnqn.fsf@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
Date: Thu, 15 Apr 2021 14:35:16 -0400
Message-ID: <87im4nief4.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:
> My preferred solution to this would be to unconditionally chown -R home
> directories upon activation

I also wonder if this could lead to security flaws similar to
CVE-2021-27851 <https://bugs.gnu.org/47229>, but perhaps 'chown' has
been written carefully to avoid such problems.

       Mark

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 Apr 2021 19:01:01 +0000
Resent-Message-ID: <handler.36508.B36508.16185132084424 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.16185132084424
          (code B ref 36508); Thu, 15 Apr 2021 19:01:01 +0000
Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 19:00:08 +0000
Received: from localhost ([127.0.0.1]:39212 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lX7Dk-00019I-ID
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 15:00:08 -0400
Received: from world.peace.net ([64.112.178.59]:40764)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lX7Dj-00017b-2a
 for 36508 <at> debbugs.gnu.org; Thu, 15 Apr 2021 15:00:07 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lX7Dc-00021r-Jm; Thu, 15 Apr 2021 15:00:00 -0400
From: Mark H Weaver <mhw@HIDDEN>
In-Reply-To: <875z0pgnqn.fsf@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
Date: Thu, 15 Apr 2021 14:58:16 -0400
Message-ID: <87eefbidcs.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:

> Mark H Weaver <mhw@HIDDEN> skribis:
>
>> Here's one idea: when activating a system, *never* delete users or
>> groups if files still exist that are owned by those users/groups.
>> Checking all filesystems would likely be too expensive, but perhaps it
>> would be sufficient to check certain directories such as /var, /etc, and
>> possibly the top directory of /home.
>
> How would you determine which directories to look at though?  What if we
> miss an important one?

I have another idea:

Maintain historical mappings from user/group names to UIDs/GIDs, perhaps
in some file in /etc, where entries are added but *never* automatically
removed.  When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the
range of those mappings.

Then, provide a UID/GID garbage collector, to be explicitly run by users
if desired, which would scan all filesystems to find the set of UID/GIDs
currently referenced, and remove entries from the historical mappings
that are no longer needed.

What do you think?

      Mark

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 Apr 2021 20:06:02 +0000
Resent-Message-ID: <handler.36508.B36508.161851714927025 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.161851714927025
          (code B ref 36508); Thu, 15 Apr 2021 20:06:02 +0000
Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 20:05:49 +0000
Received: from localhost ([127.0.0.1]:39313 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lX8FI-00071p-KT
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 16:05:49 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35706)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1lX8FG-00071a-2R
 for 36508 <at> debbugs.gnu.org; Thu, 15 Apr 2021 16:05:47 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:43756)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <ludo@HIDDEN>)
 id 1lX8FA-0006fw-8H; Thu, 15 Apr 2021 16:05:40 -0400
Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=38568 helo=ribbon)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <ludo@HIDDEN>)
 id 1lX8F8-0006Z9-Qx; Thu, 15 Apr 2021 16:05:39 -0400
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
 <87lf9jiems.fsf@HIDDEN>
X-URL: http://www.fdn.fr/~lcourtes/
X-Revolutionary-Date: 26 Germinal an 229 de la =?UTF-8?Q?R=C3=A9volution?=
X-PGP-Key-ID: 0x090B11993D9AEBB5
X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
Date: Thu, 15 Apr 2021 22:05:36 +0200
In-Reply-To: <87lf9jiems.fsf@HIDDEN> (Mark H. Weaver's message of "Thu, 15
 Apr 2021 14:30:40 -0400")
Message-ID: <878s5j8ga7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi Mark,

Mark H Weaver <mhw@HIDDEN> skribis:

> Ludovic Court=C3=A8s <ludo@HIDDEN> writes:
>
>> Note that there are other places, in addition to GDM, where we
>> forcefully reset the UID/GID of the home directory (e.g., for the
>> =E2=80=98knot-resolver=E2=80=99 service.)
>>
>> My preferred solution to this would be to unconditionally chown -R home
>> directories upon activation (for efficiency, it would be best if we
>> could do that if and only if the home directory itself has wrong
>> ownership).  Thoughts?
>
> It might be okay to do this in specific cases like /var/lib/gdm, but I'm
> very uncomfortable doing it for *all* users, because:
>
> (1) We shouldn't assume that all files within a home directory are
>     supposed to be owned by that user.
>
> (2) We shouldn't assume that all files owned by a user will be within
>     their home directory.
>
> (3) We shouldn't assume that all files within a home directory are
>     supposed to have the same 'group'.  I, for one, have sometimes had
>     subdirectories of my home directory with a different 'group', to
>     either restrict or grant other users access to selected files or
>     directories.
>
> (4) Groups do not, in general, have home directories.
>
> (5) I consider it unsatifactory for there to be *any* window of time
>     during system activation when the ownership of files is incorrect.

I agree this raises questions and we should take time to think through
it.  For system accounts though, I think 1=E2=80=934 do not apply.

Perhaps a first step would be to do that for system accounts?

>> Note that the ID allocation strategy in (gnu build accounts) ensures
>> UIDs/GIDs aren=E2=80=99t reused right away (same strategy as implemented=
 by
>> Shadow, etc.).  So if you remove =E2=80=9Cbob=E2=80=9D, then add =E2=80=
=9Calice=E2=80=9D, =E2=80=9Calice=E2=80=9D won=E2=80=99t
>> be able to access the left-behind /home/bob because it has a different
>> UID.

To be clear, it=E2=80=99s doing the same as any other GNU/Linux distro.

> This mechanism is insufficient, because it only avoids the problem if
> you add "alice" at the same time that "bob" is removed.  If you remove
> "bob" during one system activation, and then later add "alice", then
> "alice" might well be able to access bob's left-behind files.
>
> In the case that I personally witnessed on my Guix system, files within
> /var/lib/gdm ended up with 'colord' as their group.  That's not good.
>
> Increasingly, I'm leaning toward the idea that the complete mapping from
> names to IDs should somehow be explicitly given as part of the OS
> configuration, as I advocated in <https://bugs.gnu.org/36508#26>.
>
> What do you think?

IDs as hash of the user names are interesting because that=E2=80=99d be
stateless (conversely, the current ID allocation strategy is stateful:
it arranges to not reuse recently-freed IDs.)

But like you write, we=E2=80=99d need 32-bit UIDs.  In libc, =E2=80=98uid_t=
=E2=80=99
(specifically =E2=80=98__UID_T_TYPE=E2=80=99 in typesizes.h) is 32-bit, so =
it might work
rather well in user space.

It still sounds like a change with significant implications though, and
it=E2=80=99s hard to predict exactly how it would go or what would break.  =
For
example, that does away with the system/non-system ranges, and wouldn=E2=80=
=99t
play well with =E2=80=9Cspecial=E2=80=9D IDs like 0 and 65535.

To me, it=E2=80=99s a potential way out, but not a solution for the bug Bre=
ndan
reported today, nor a change we could implement in the coming
weeks/months; the time scale is probably longer.

WDYT?

Thanks,
Ludo=E2=80=99.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 Apr 2021 22:25:02 +0000
Resent-Message-ID: <handler.36508.B36508.161852548215460 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.161852548215460
          (code B ref 36508); Thu, 15 Apr 2021 22:25:02 +0000
Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 22:24:42 +0000
Received: from localhost ([127.0.0.1]:39465 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXAPi-00041I-Dq
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 18:24:42 -0400
Received: from world.peace.net ([64.112.178.59]:41266)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lXAPh-000415-5E
 for 36508 <at> debbugs.gnu.org; Thu, 15 Apr 2021 18:24:41 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lXAPa-00085V-0Y; Thu, 15 Apr 2021 18:24:34 -0400
From: Mark H Weaver <mhw@HIDDEN>
In-Reply-To: <878s5j8ga7.fsf@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
 <87lf9jiems.fsf@HIDDEN> <878s5j8ga7.fsf@HIDDEN>
Date: Thu, 15 Apr 2021 18:22:49 -0400
Message-ID: <87zgxzgpbf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Ludovic,

Ludovic Court=C3=A8s <ludo@HIDDEN> wrote:
>>> Note that the ID allocation strategy in (gnu build accounts) ensures
>>> UIDs/GIDs aren=E2=80=99t reused right away (same strategy as implemente=
d by
>>> Shadow, etc.).  So if you remove =E2=80=9Cbob=E2=80=9D, then add =E2=80=
=9Calice=E2=80=9D, =E2=80=9Calice=E2=80=9D won=E2=80=99t
>>> be able to access the left-behind /home/bob because it has a different
>>> UID.

I replied:
>> This mechanism is insufficient, because it only avoids the problem if
>> you add "alice" at the same time that "bob" is removed.  If you remove
>> "bob" during one system activation, and then later add "alice", then
>> "alice" might well be able to access bob's left-behind files.

Ludovic Court=C3=A8s <ludo@HIDDEN> responded:
> To be clear, it=E2=80=99s doing the same as any other GNU/Linux distro.

I don't think that's quite right.

It's true that if you delete a user or group on another distro and then
re-add it, it might not be assigned the same UID/GID.  That much is the
same as any other distro.

The key difference is this: On Debian, at least in my experience, users
and groups are *never* deleted automatically.  They are only added
automatically, but never removed unless you explicitly ask to remove
them.  So, this problem does not arise in practice.

      Thanks,
        Mark

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 Apr 2021 23:07:02 +0000
Resent-Message-ID: <handler.36508.B36508.161852798419354 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.161852798419354
          (code B ref 36508); Thu, 15 Apr 2021 23:07:02 +0000
Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 23:06:24 +0000
Received: from localhost ([127.0.0.1]:39523 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXB44-000525-MT
	for submit <at> debbugs.gnu.org; Thu, 15 Apr 2021 19:06:24 -0400
Received: from world.peace.net ([64.112.178.59]:41330)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lXB41-00051o-38
 for 36508 <at> debbugs.gnu.org; Thu, 15 Apr 2021 19:06:24 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lXB3u-0002Zm-Ox; Thu, 15 Apr 2021 19:06:14 -0400
From: Mark H Weaver <mhw@HIDDEN>
In-Reply-To: <878s5j8ga7.fsf@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
 <87lf9jiems.fsf@HIDDEN> <878s5j8ga7.fsf@HIDDEN>
Date: Thu, 15 Apr 2021 19:04:30 -0400
Message-ID: <87wnt3gndy.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Ludovic,

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:

> IDs as hash of the user names are interesting because that=E2=80=99d be
> stateless (conversely, the current ID allocation strategy is stateful:
> it arranges to not reuse recently-freed IDs.)
>
> But like you write, we=E2=80=99d need 32-bit UIDs.  In libc, =E2=80=98uid=
_t=E2=80=99
> (specifically =E2=80=98__UID_T_TYPE=E2=80=99 in typesizes.h) is 32-bit, s=
o it might work
> rather well in user space.

The kernel and core system components certainly support 32-bit UIDs, and
have for around 20 years.

> It still sounds like a change with significant implications though, and
> it=E2=80=99s hard to predict exactly how it would go or what would break.

Right, my concern is with the vast majority of programs and libraries in
Guix, most of which probably haven't seen much (if any) testing with
large UIDs.

> For example, that does away with the system/non-system ranges, and
> wouldn=E2=80=99t play well with =E2=80=9Cspecial=E2=80=9D IDs like 0 and =
65535.

This particular issue is easily addressed.  It's easy enough to find a
function from 31-hash values to 32-bit IDs that's injective and avoids
any chosen subset of special IDs, as long as there are fewer than 2^31
special IDs.

Simply adding 65536 (or even 2^31) to the hash value would be one easy
option.

What do you think?

       Mark

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 16 Apr 2021 10:44:02 +0000
Resent-Message-ID: <handler.36508.B36508.16185697945116 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.16185697945116
          (code B ref 36508); Fri, 16 Apr 2021 10:44:02 +0000
Received: (at 36508) by debbugs.gnu.org; 16 Apr 2021 10:43:14 +0000
Received: from localhost ([127.0.0.1]:40105 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXLwQ-0001KR-5C
	for submit <at> debbugs.gnu.org; Fri, 16 Apr 2021 06:43:14 -0400
Received: from xavier.telenet-ops.be ([195.130.132.52]:33434)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1lXLwM-0001KG-Ni
 for 36508 <at> debbugs.gnu.org; Fri, 16 Apr 2021 06:43:12 -0400
Received: from ptr-bvsjgyjmffd7q9timvx.18120a2.ip6.access.telenet.be
 ([IPv6:2a02:1811:8c09:9d00:aaf1:9810:a0b8:a55d])
 by xavier.telenet-ops.be with bizsmtp
 id tNj82400K0mfAB401Nj8Un; Fri, 16 Apr 2021 12:43:09 +0200
Message-ID: <38fd9bfdc71c689df1606a0b00d632e423c5defa.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
Date: Fri, 16 Apr 2021 12:42:53 +0200
In-Reply-To: <87eefbidcs.fsf@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
 <87eefbidcs.fsf@HIDDEN>
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-vI66qH0XHOizTwd9LNSk"
User-Agent: Evolution 3.34.2 
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21;
 t=1618569789; bh=6fK+zfjLWh0vsbQPCEOwSVJVNlEj7zV+JoyaknT3oFU=;
 h=Subject:From:To:Cc:Date:In-Reply-To:References;
 b=ODBkCkzDv+orOTIP6prKoFg+po0S5xknwhiv2Sm66HF1UrE+6lCEvlHwjdLZeEWEa
 8Hav+/J0O1WtL5+wjRESNwhnNbUy1/ofQWR07cBpwIHyuChXBCRSEltID+M4OCGb/2
 LPas723h5PDHNTqrsZzTjfnhtslRCihz6J4QI9rdPGUmFFiUs/ByEEEfMpGaUlMb5m
 y8z+jVcNaCMxYoLxG0nxYrJUwb2QVVQCIU56qjoQvOnCO5YSvJuQDIEkS60gI4AP90
 cepgikjhWukKQkbTwNI+sdw15oDBnpeZKPMaiZ4Ci/wZX/QV6urJeqBDkOOr9fHOZM
 mhwGWvj9QNGJg==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)


--=-vI66qH0XHOizTwd9LNSk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2021-04-15 at 14:58 -0400, Mark H Weaver wrote:
> Ludovic Court=C3=A8s <ludo@HIDDEN> writes:
>=20
> > Mark H Weaver <mhw@HIDDEN> skribis:
> >=20
> > > Here's one idea: when activating a system, *never* delete users or
> > > groups if files still exist that are owned by those users/groups.
> > > Checking all filesystems would likely be too expensive, but perhaps i=
t
> > > would be sufficient to check certain directories such as /var, /etc, =
and
> > > possibly the top directory of /home.

And /tmp, /media and /run/user.

> >=20
> > How would you determine which directories to look at though?  What if w=
e
> > miss an important one?
>=20
> I have another idea:
>=20
> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps
> in some file in /etc, where entries are added but *never* automatically
> removed.  When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the
> range of those mappings.

This seems rather convoluted to me.  Why not reuse /etc/passwd and /etc/gro=
ups?
My suggestion:

1. *never* automatically delete users/groups from /etc/passwd, /etc/groups
   (I thought that was how Guix already worked ...)
2. as users and groups appearing in /etc/passwd and /etc/groups, but not
   in the operating system configuration can be confusing, change the comme=
nt
   string of these users and groups, to something like

   "account removed"

   Add a group 'user-graveyard' for (3), and move these 'pseudo-removed' us=
ers
   to the 'user-graveyard' group.
3. Don't forget to remove graveyard users from all groups (except user-grav=
eyard),
   make sure the graveyard users can't log in anymore ... (Perhaps add a ru=
le to
   the SSH and PAM configuration that forbids logging in to graveyard accou=
nts,
   by checking whether the user is in the 'user-graveyard' group?)

> Then, provide a UID/GID garbage collector, to be explicitly run by users
> if desired, which would scan all filesystems to find the set of UID/GIDs
> currently referenced, and remove entries from the historical mappings
> that are no longer needed.

That seems useful for if /etc/passwd and /etc/group is getting full, or jus=
t for
cleaning up.  You may want to exclude /gnu/store though, for efficiency (-:=
.
And just in case check whether any live processes have the UID/GID.

Suggested command name: "guix user-gc".

Greetings,
Maxime.

--=-vI66qH0XHOizTwd9LNSk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYHlqLRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7iLeAQCDp8ywXTcQrPOsnQ427HUGcXmo
W23thxgqzXqSPwy5ZAD9EoGaIgOLrMymibzhCeJ/alf6nGRxQjonoxZ9cyuq5A0=
=Ht7l
-----END PGP SIGNATURE-----

--=-vI66qH0XHOizTwd9LNSk--

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 16 Apr 2021 15:15:02 +0000
Resent-Message-ID: <handler.36508.B36508.16185860627579 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.16185860627579
          (code B ref 36508); Fri, 16 Apr 2021 15:15:02 +0000
Received: (at 36508) by debbugs.gnu.org; 16 Apr 2021 15:14:22 +0000
Received: from localhost ([127.0.0.1]:41424 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXQAo-0001yA-8f
	for submit <at> debbugs.gnu.org; Fri, 16 Apr 2021 11:14:22 -0400
Received: from eggs.gnu.org ([209.51.188.92]:44690)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1lXQAm-0001xr-Jr
 for 36508 <at> debbugs.gnu.org; Fri, 16 Apr 2021 11:14:20 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:41997)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <ludo@HIDDEN>)
 id 1lXQAg-0000WS-EO; Fri, 16 Apr 2021 11:14:14 -0400
Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=39090 helo=ribbon)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <ludo@HIDDEN>)
 id 1lXQAf-0001de-W1; Fri, 16 Apr 2021 11:14:14 -0400
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
 <87lf9jiems.fsf@HIDDEN> <878s5j8ga7.fsf@HIDDEN>
 <87wnt3gndy.fsf@HIDDEN>
X-URL: http://www.fdn.fr/~lcourtes/
X-Revolutionary-Date: 27 Germinal an 229 de la =?UTF-8?Q?R=C3=A9volution?=
X-PGP-Key-ID: 0x090B11993D9AEBB5
X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
Date: Fri, 16 Apr 2021 17:14:11 +0200
In-Reply-To: <87wnt3gndy.fsf@HIDDEN> (Mark H. Weaver's message of "Thu, 15
 Apr 2021 19:04:30 -0400")
Message-ID: <871rba5kjg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi Mark,

Mark H Weaver <mhw@HIDDEN> skribis:

> This particular issue is easily addressed.  It's easy enough to find a
> function from 31-hash values to 32-bit IDs that's injective and avoids
> any chosen subset of special IDs, as long as there are fewer than 2^31
> special IDs.
>
> Simply adding 65536 (or even 2^31) to the hash value would be one easy
> option.
>
> What do you think?

Yes, but these special IDs are just examples of things that could go
wrong.  I don=E2=80=99t know, maybe I=E2=80=99m just overly cautious; we ha=
ve to try to
get a better understanding of how things will go!

Thanks,
Ludo=E2=80=99.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 16 Apr 2021 15:19:01 +0000
Resent-Message-ID: <handler.36508.B36508.16185862967991 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.16185862967991
          (code B ref 36508); Fri, 16 Apr 2021 15:19:01 +0000
Received: (at 36508) by debbugs.gnu.org; 16 Apr 2021 15:18:16 +0000
Received: from localhost ([127.0.0.1]:41435 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXQEZ-00024o-PQ
	for submit <at> debbugs.gnu.org; Fri, 16 Apr 2021 11:18:16 -0400
Received: from eggs.gnu.org ([209.51.188.92]:45860)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1lXQEX-00024b-Mn
 for 36508 <at> debbugs.gnu.org; Fri, 16 Apr 2021 11:18:14 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:42068)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <ludo@HIDDEN>)
 id 1lXQES-0002Dg-HG; Fri, 16 Apr 2021 11:18:08 -0400
Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=39092 helo=ribbon)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <ludo@HIDDEN>)
 id 1lXQES-0001y5-23; Fri, 16 Apr 2021 11:18:08 -0400
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
 <87lf9jiems.fsf@HIDDEN> <878s5j8ga7.fsf@HIDDEN>
 <87zgxzgpbf.fsf@HIDDEN>
X-URL: http://www.fdn.fr/~lcourtes/
X-Revolutionary-Date: 27 Germinal an 229 de la =?UTF-8?Q?R=C3=A9volution?=
X-PGP-Key-ID: 0x090B11993D9AEBB5
X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
Date: Fri, 16 Apr 2021 17:18:06 +0200
In-Reply-To: <87zgxzgpbf.fsf@HIDDEN> (Mark H. Weaver's message of "Thu, 15
 Apr 2021 18:22:49 -0400")
Message-ID: <87tuo645sh.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi,

Mark H Weaver <mhw@HIDDEN> skribis:

> It's true that if you delete a user or group on another distro and then
> re-add it, it might not be assigned the same UID/GID.  That much is the
> same as any other distro.
>
> The key difference is this: On Debian, at least in my experience, users
> and groups are *never* deleted automatically.  They are only added
> automatically, but never removed unless you explicitly ask to remove
> them.  So, this problem does not arise in practice.

>> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps
>> in some file in /etc, where entries are added but *never* automatically
>> removed.  When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the
>> range of those mappings.

If we=E2=80=99re just worried about ID allocation, we could keep state in, =
say,
/etc/previous-uids, and feed that as input to the (gnu build accounts)
allocation code.

Thoughts?

Maxime Devos <maximedevos@HIDDEN> skribis:

> This seems rather convoluted to me.  Why not reuse /etc/passwd and /etc/g=
roups?
> My suggestion:
>
> 1. *never* automatically delete users/groups from /etc/passwd, /etc/groups
>    (I thought that was how Guix already worked ...)
> 2. as users and groups appearing in /etc/passwd and /etc/groups, but not
>    in the operating system configuration can be confusing, change the com=
ment
>    string of these users and groups, to something like
>
>    "account removed"
>
>    Add a group 'user-graveyard' for (3), and move these 'pseudo-removed' =
users
>    to the 'user-graveyard' group.
> 3. Don't forget to remove graveyard users from all groups (except user-gr=
aveyard),
>    make sure the graveyard users can't log in anymore ... (Perhaps add a =
rule to
>    the SSH and PAM configuration that forbids logging in to graveyard acc=
ounts,
>    by checking whether the user is in the 'user-graveyard' group?)

Problem is that things like GDM would still propose those old accounts
(unless maybe their password is uninitialized, I=E2=80=99m not sure; but it=
=E2=80=99s
still hacky.)

Thanks,
Ludo=E2=80=99.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 17 Apr 2021 16:19:01 +0000
Resent-Message-ID: <handler.36508.B36508.161867632216550 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.161867632216550
          (code B ref 36508); Sat, 17 Apr 2021 16:19:01 +0000
Received: (at 36508) by debbugs.gnu.org; 17 Apr 2021 16:18:42 +0000
Received: from localhost ([127.0.0.1]:44212 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXneb-0004Is-Oe
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:18:41 -0400
Received: from world.peace.net ([64.112.178.59]:45424)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lXnea-0004If-6i
 for 36508 <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:18:40 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lXneT-0003aW-22; Sat, 17 Apr 2021 12:18:33 -0400
From: Mark H Weaver <mhw@HIDDEN>
In-Reply-To: <87tuo645sh.fsf@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
 <87lf9jiems.fsf@HIDDEN> <878s5j8ga7.fsf@HIDDEN>
 <87zgxzgpbf.fsf@HIDDEN> <87tuo645sh.fsf@HIDDEN>
Date: Sat, 17 Apr 2021 12:16:43 -0400
Message-ID: <87blac9989.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Ludovic,

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:

> Mark H Weaver <mhw@HIDDEN> skribis:
>
>>> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps
>>> in some file in /etc, where entries are added but *never* automatically
>>> removed.  When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the
>>> range of those mappings.
>
> If we=E2=80=99re just worried about ID allocation, we could keep state in=
, say,
> /etc/previous-uids, and feed that as input to the (gnu build accounts)
> allocation code.

Sounds good to me, or at least better than the other available options.

     Thanks,
       Mark

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#36508: GDM files have incorrect owner after temporarily removing service
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 17 Apr 2021 16:31:01 +0000
Resent-Message-ID: <handler.36508.B36508.161867700917691 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 36508
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Maxime Devos <maximedevos@HIDDEN>, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Brendan Tildesley <btild@HIDDEN>, 36508 <at> debbugs.gnu.org
Received: via spool by 36508-submit <at> debbugs.gnu.org id=B36508.161867700917691
          (code B ref 36508); Sat, 17 Apr 2021 16:31:01 +0000
Received: (at 36508) by debbugs.gnu.org; 17 Apr 2021 16:30:09 +0000
Received: from localhost ([127.0.0.1]:44230 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXnpg-0004bH-OT
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:30:09 -0400
Received: from world.peace.net ([64.112.178.59]:45450)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1lXnpe-0004ZN-OH
 for 36508 <at> debbugs.gnu.org; Sat, 17 Apr 2021 12:30:07 -0400
Received: from mhw by world.peace.net with esmtpsa
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92)
 (envelope-from <mhw@HIDDEN>)
 id 1lXnpX-0004Pf-NV; Sat, 17 Apr 2021 12:29:59 -0400
From: Mark H Weaver <mhw@HIDDEN>
In-Reply-To: <38fd9bfdc71c689df1606a0b00d632e423c5defa.camel@HIDDEN>
References: <20190705083620.lbzu7a33awbymh3d@cf0>
 <1576552162.14721.1618320275616@HIDDEN>
 <87czuxsya5.fsf@HIDDEN> <875z0pgnqn.fsf@HIDDEN>
 <87eefbidcs.fsf@HIDDEN>
 <38fd9bfdc71c689df1606a0b00d632e423c5defa.camel@HIDDEN>
Date: Sat, 17 Apr 2021 12:28:10 -0400
Message-ID: <878s5g98p6.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Maxime,

Maxime Devos <maximedevos@HIDDEN> writes:

> On Thu, 2021-04-15 at 14:58 -0400, Mark H Weaver wrote:
>> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps
>> in some file in /etc, where entries are added but *never* automatically
>> removed.  When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the
>> range of those mappings.
>
> This seems rather convoluted to me.  Why not reuse /etc/passwd and /etc/groups?
> My suggestion:
>
> 1. *never* automatically delete users/groups from /etc/passwd, /etc/groups
>    (I thought that was how Guix already worked ...)
> 2. as users and groups appearing in /etc/passwd and /etc/groups, but not
>    in the operating system configuration can be confusing, change the comment
>    string of these users and groups, to something like
>
>    "account removed"
>
>    Add a group 'user-graveyard' for (3), and move these 'pseudo-removed' users
>    to the 'user-graveyard' group.
> 3. Don't forget to remove graveyard users from all groups (except user-graveyard),
>    make sure the graveyard users can't log in anymore ... (Perhaps add a rule to
>    the SSH and PAM configuration that forbids logging in to graveyard accounts,
>    by checking whether the user is in the 'user-graveyard' group?)

I would be okay with this approach as well, although it's not obvious to
me that it's any cleaner than having a separate /etc/previous-uids file,
given items 2 and 3 above.

>> Then, provide a UID/GID garbage collector, to be explicitly run by users
>> if desired, which would scan all filesystems to find the set of UID/GIDs
>> currently referenced, and remove entries from the historical mappings
>> that are no longer needed.
>
> That seems useful for if /etc/passwd and /etc/group is getting full, or just for
> cleaning up.  You may want to exclude /gnu/store though, for efficiency (-:.

Good point!  That's one directory that would clearly be a waste to scan :-)

> And just in case check whether any live processes have the UID/GID.

Sure, sounds good.

     Thanks!
       Mark

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 9 May 2021 16:46:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 09 12:46:38 2021
Received: from localhost ([127.0.0.1]:56235 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lfmZh-0002tp-N2
	for submit <at> debbugs.gnu.org; Sun, 09 May 2021 12:46:37 -0400
Received: from out2-smtp.messagingengine.com ([66.111.4.26]:37733)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <leo@HIDDEN>) id 1lfmZd-0002mT-Rt
 for control <at> debbugs.gnu.org; Sun, 09 May 2021 12:46:36 -0400
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
 by mailout.nyi.internal (Postfix) with ESMTP id 8E6EC5C0105;
 Sun,  9 May 2021 12:46:28 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute2.internal (MEProxy); Sun, 09 May 2021 12:46:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name;
 h=date:from:to:message-id:mime-version:content-type; s=mesmtp;
 bh=pHwQJcL0KvdJxA01VAqnRMrhWC7faDuhQJHA4sjMXu0=; b=VrFjlSPmDLQA
 XEg4UvsBkibB4mAO3nRQJhqOsMZUNq+32PblO/YwBVVDUDfeYwoxqdaIPNt8vzTP
 C/wMNeHy1otYyW3NOTTrhv1Xrw8jbpmpiAVGFpMjk1wPM/jQEgJsVKcE4BtrxDvD
 cbfASJfzG5h4crFQQRL0zwHm5I+jfBI=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=content-type:date:from:message-id
 :mime-version:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm2; bh=pHwQJcL0KvdJxA01VAqnRMrhWC7faDuhQJHA4sjMX
 u0=; b=oz/l7h4KGyXBrmp+fG0jTsPK5T7+r+bPNUEoGJJ+uemEEA5Zi3Rd9+3Vq
 j4wpu+MKEuLzn8wgp4gyS1qIOFIzp2ji7ePMtKQ5ha10r2l0+lryPIsd9jarSXVV
 ovm1mkQBimGpeyojHhW+9jDiyQ2AMgO+gg1omjejPq3FJb4ISUapN/ilTkhhEQl1
 JQ0qxGhbI9kW6BKD6FE6rYSZRREHejy5hzfNerIOc+b0oTvVYZBmkJcWrehhKkdt
 xogROUqGSjSrGQ69O1aIEYHMGm6CbWgFCN+kAqVw0yYwAuuEg6KZfwuG++/DD2IV
 bWaeoDka5GIEQlrGIWA96GafpmB9w==
X-ME-Sender: <xms:5BGYYHyJ5TyWI3Jqp_u-Vb5pDfwasGhU3fE9vESDkiX5aQL8wEx7zw>
 <xme:5BGYYPQNh7XIptMbKcmdhyhoc4DYkqgsnNWDbd06IHK3BbzV7QLWOJsikd3kP3PuP
 bJ4QrvQHe4rs5MHZA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdegiedguddtjecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecugfhmphhthicushhusghjvggtthculddutddmne
 cujfgurhepfffhvffkgggtugesthdtredttddtvdenucfhrhhomhepnfgvohcuhfgrmhhu
 lhgrrhhiuceolhgvohesfhgrmhhulhgrrhhirdhnrghmvgeqnecuggftrfgrthhtvghrnh
 ephfejiefgfeevvdefteehgeeltdekvedutdegtdduieetheetgedvfeffudfffeffnecu
 kfhppedutddtrdduuddrudeiledruddukeenucevlhhushhtvghrufhiiigvpedtnecurf
 grrhgrmhepmhgrihhlfhhrohhmpehlvghosehfrghmuhhlrghrihdrnhgrmhgv
X-ME-Proxy: <xmx:5BGYYBWBWg3xgUouc780hV5nt21XlA85XX_6-SiiHQBCuCedWZAXRg>
 <xmx:5BGYYBhAwXlCdBWv0ar85jCwCy-6sPhyjSzBesVcyzaBd6v48yjV7Q>
 <xmx:5BGYYJCeQZlC8E0uvnoM3hzu9tjoW6AJ9Yk_PJ3zJWKarA2g0H45Ag>
 <xmx:5BGYYMMnN9m13O2Nj9oBjCwkbcSvh850H6eDmXtsHo3aNm3P86qy0A>
Received: from localhost (pool-100-11-169-118.phlapa.fios.verizon.net
 [100.11.169.118]) by mail.messagingengine.com (Postfix) with ESMTPA
 for <control <at> debbugs.gnu.org>; Sun,  9 May 2021 12:46:28 -0400 (EDT)
Date: Sun, 9 May 2021 12:46:26 -0400
From: Leo Famulari <leo@HIDDEN>
To: control <at> debbugs.gnu.org
Message-ID: <YJgR4pYFIV9kC1Z3@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  merge 39527 36508 
 Content analysis details:   (1.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [66.111.4.26 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [66.111.4.26 listed in wl.mailspike.net]
 1.8 MISSING_SUBJECT        Missing Subject: header
 0.2 NO_SUBJECT             Extra score for no subject
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

merge 39527 36508

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 9 May 2021 16:51:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 09 12:51:38 2021
Received: from localhost ([127.0.0.1]:56264 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lfmeY-0003iU-OC
	for submit <at> debbugs.gnu.org; Sun, 09 May 2021 12:51:38 -0400
Received: from mout-p-101.mailbox.org ([80.241.56.151]:58298)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mail@HIDDEN>) id 1lfmeX-0003iO-Dw
 for control <at> debbugs.gnu.org; Sun, 09 May 2021 12:51:37 -0400
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest
 SHA256) (No client certificate requested)
 by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4FdVZW2CVwzQjxR
 for <control <at> debbugs.gnu.org>; Sun,  9 May 2021 18:51:31 +0200 (CEST)
X-Virus-Scanned: amavisd-new at heinlein-support.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brendan.scot;
 s=MBO0001; t=1620579089;
 h=from:from:reply-to:subject:date:date:message-id:message-id:to:to:cc:
 mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding;
 bh=pHwQJcL0KvdJxA01VAqnRMrhWC7faDuhQJHA4sjMXu0=;
 b=kHYJEEp5Gr2g/+MQJBUJLk1WqjU1jYeh9jGwSkG+hi9m/iUbh9XCK4kPhTZicFjuSEhcA3
 /vaGLlcdoWHVPrJqsxVu0pGZCJJTi5ztcAAKjSzx5kvwh/p4pvzTdaHX1yiACk0gp4nni/
 UyzXgB9Y5aK+e+i7fvaNERdpYICKHg92VSIf70BYQ2ToYRyDct6TBTxS2OyoFrXQ3ZphJ7
 ADRJK+JXLvyaFjPlcvvyl4xLP4dpVkwVJhXj0LFov29T3cVNFZv6HynNwU+wLdeWN2QEZK
 NCfTWUACiDfKClDi7HE2lg0EdFTI+8nhY5E8tUUxq862pFYNnLr59VlIMBcWOw==
Received: from smtp2.mailbox.org ([80.241.60.241])
 by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de
 [80.241.56.115]) (amavisd-new, port 10030)
 with ESMTP id uugWwzEq1CI4 for <control <at> debbugs.gnu.org>;
 Sun,  9 May 2021 18:51:28 +0200 (CEST)
To: control <at> debbugs.gnu.org
From: Brendan Tildesley <mail@HIDDEN>
Message-ID: <dbff5319-5c49-0891-5fc9-0c67b4e213bb@HIDDEN>
Date: Mon, 10 May 2021 02:51:24 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-MBO-SPAM-Probability: *
X-Rspamd-Score: 0.19 / 15.00 / 15.00
X-Rspamd-Queue-Id: 7431D17BE
X-Rspamd-UID: c39069
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  merge 39527 36508 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [80.241.56.151 listed in list.dnswl.org]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.8 MISSING_SUBJECT        Missing Subject: header
 0.2 NO_SUBJECT             Extra score for no subject
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

merge 39527 36508

Last modified: Sun, 9 May 2021 17:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.