X-Loop: help-debbugs@HIDDEN
Subject: bug#78355: guix-ownership inconsistent state
Resent-From: Rutherther <rutherther@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: ludo@HIDDEN, bug-guix@HIDDEN
Resent-Date: Sat, 10 May 2025 15:35:01 +0000
Resent-Message-ID: <handler.78355.B.1746891263371 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 78355
X-GNU-PR-Package: guix
X-GNU-PR-Keywords:
To: 78355 <at> debbugs.gnu.org
Cc: ludo@HIDDEN
X-Debbugs-Original-To: bug-guix@HIDDEN
X-Debbugs-Original-Xcc: ludo@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.1746891263371
(code B ref -1); Sat, 10 May 2025 15:35:01 +0000
Received: (at submit) by debbugs.gnu.org; 10 May 2025 15:34:23 +0000
Received: from localhost ([127.0.0.1]:48265 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDmDX-00005u-2m
for submit <at> debbugs.gnu.org; Sat, 10 May 2025 11:34:23 -0400
Received: from lists.gnu.org ([2001:470:142::17]:46910)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <rutherther@HIDDEN>)
id 1uDmDU-00005K-Hx
for submit <at> debbugs.gnu.org; Sat, 10 May 2025 11:34:21 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <rutherther@HIDDEN>)
id 1uDmDG-000572-7K
for bug-guix@HIDDEN; Sat, 10 May 2025 11:34:07 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::] helo=mail.ditigal.xyz)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256)
(Exim 4.90_1) (envelope-from <rutherther@HIDDEN>)
id 1uDmDD-0003DM-CF
for bug-guix@HIDDEN; Sat, 10 May 2025 11:34:05 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 66d8be0f
(TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO) for <bug-guix@HIDDEN>;
Sat, 10 May 2025 15:33:58 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
Date: Sat, 10 May 2025 17:33:56 +0200
Message-ID: <87tt5sjx97.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
i=@ditigal.xyz; q=dns/txt; s=20240917; t=1746891238; h=from : to :
subject : date : message-id : mime-version : content-type : from;
bh=lSlDEuauDctdro3L+96w0wMzsR2FNiLn9f7JIB0Prv0=;
b=U9xGN6LZ3HryBxVYDA8jTv6sDpYiVaH4iurvZw8NUPLRTZYNUmKd4WRnfx26n9tzFQJ8h
nLzfhXwCPbqqMSLquuQ095jCLC3gGAwdmC70DjVojSfznvxAzz0dmYfDQGgg+rIO/XRvGtw
Gr8J8f/yJVSW8HxsDsWoEzBGHJtKTeQ=
Received-SPF: pass client-ip=2a01:4f8:1c1b:6a1c::;
envelope-from=rutherther@HIDDEN; helo=mail.ditigal.xyz
X-Spam_score_int: 4
X-Spam_score: 0.4
X-Spam_bar: /
X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499,
FROM_SUSPICIOUS_NTLD_FP=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 3.4 (+++)
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: There are reports from users with inconsistencies in
ownership,
it seems that at least /var/guix is sometimes left with wrong owner, but
maybe even parts of the store? I cannot verify that. The guix-ownership
service
checks /gnu/store ownership to check if the whole store and all files
important
for the daemon (/etc/guix, /var/guix) are owned by the appropriate user.
Content analysis details: (3.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.9 SPF_FAIL SPF: sender does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
id=rutherther%40ditigal.xyz; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
0.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
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: 2.4 (++)
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: There are reports from users with inconsistencies in ownership,
it seems that at least /var/guix is sometimes left with wrong owner, but
maybe even parts of the store? I cannot verify that. The guix-ownership service
checks /gnu/store ownership to check if the whole store and all files important
for the daemon (/etc/guix, /var/guix) are owned by the appropriate user.
Content analysis details: (2.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2001:470:142:0:0:0:0:17 listed in]
[list.dnswl.org]
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.9 SPF_FAIL SPF: sender does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.org/Why?s=mfrom;id=rutherther%40ditigal.xyz;ip=2001%3A470%3A142%3A%3A17;r=debbugs.gnu.org]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
There are reports from users with inconsistencies in ownership, it seems that at
least /var/guix is sometimes left with wrong owner, but maybe even parts
of the store? I cannot verify that.
The guix-ownership service checks /gnu/store ownership to check if the
whole store and all files important for the daemon (/etc/guix,
/var/guix) are owned by the appropriate user.
If the folder isn't owned by appropriate user, it moves to those steps:
1. Fix permissions in /gnu/store - first under it, then /gnu/store
itself as last step
2. Fix /var/guix
3. Fix /etc/guix
4. Fix /var/log/guix
So from those laid out steps it should be obvious that if guix-ownership
service somehow stops between steps 1 and 2, it will never recover
ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
change owner as last.
On the other hand it feels much of a coincidence users would be
consistently hitting reboots between those steps. So maybe I am
overlooking another thing. I checked the file-system-fold, it goes to
/gnu/store as last, so that would mean putting step 1 after 4 should fix
that. Still, maybe only /gnu/store itself should be skipped instead of moving
the step, and done as last, step 5 to ensure it's fine even if
file-system-fold somehow changed the ordering? Not sure how exactly it
should behave in that regard.
Regards
Rutherther
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: Rutherther <rutherther@HIDDEN> Subject: bug#78355: Acknowledgement (guix-ownership inconsistent state) Message-ID: <handler.78355.B.1746891263371.ack <at> debbugs.gnu.org> References: <87tt5sjx97.fsf@HIDDEN> X-Gnu-PR-Message: ack 78355 X-Gnu-PR-Package: guix Reply-To: 78355 <at> debbugs.gnu.org Date: Sat, 10 May 2025 15:35: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. As you requested using X-Debbugs-CC, your message was also forwarded to ludo@HIDDEN (after having been given a bug report number, if it did not have one). 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 78355 <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 78355: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78355 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN
Subject: bug#78355: guix-ownership inconsistent state
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 May 2025 21:52:05 +0000
Resent-Message-ID: <handler.78355.B78355.174725949922315 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78355
X-GNU-PR-Package: guix
X-GNU-PR-Keywords:
To: Rutherther <rutherther@HIDDEN>
Cc: 78355 <at> debbugs.gnu.org
Received: via spool by 78355-submit <at> debbugs.gnu.org id=B78355.174725949922315
(code B ref 78355); Wed, 14 May 2025 21:52:05 +0000
Received: (at 78355) by debbugs.gnu.org; 14 May 2025 21:51:39 +0000
Received: from localhost ([127.0.0.1]:46795 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uFK0n-0005nZ-Hw
for submit <at> debbugs.gnu.org; Wed, 14 May 2025 17:51:38 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47084)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uFK0G-0005iF-AO
for 78355 <at> debbugs.gnu.org; Wed, 14 May 2025 17:51:04 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
id 1uFK0A-0007w6-QP; Wed, 14 May 2025 17:50:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
From; bh=U/ASJiUfRTV28p5v/XXtxNjU6KAOpcKv4473gF8ftwQ=; b=OG/zT7paD5NdVB+2d4gy
2BGXvZpO+Qg358QDSihWrnc8WgCEAMcKbGZSugXQnFaHH7Ewfd11ET29L3sw/blLcCplctpgKrAI3
Q+Pi4mUvNYcGmn8e77BCSs6mSW7jGRSG1oth88efkzevS+EReJsIhQy1UiKzvhl2EuT31b/SvEcmb
MqVAeZb2LIXDFOUDsFfU6A8skXqnlY5NDlo3Ciz3HhiqG7cWkO+aHDO/VpcI8u6f3a8DkVIFo6Jc2
JD8RpcpIo1469ykS6Vkr8Cgkb8TEVEhiEsKVwwUv0jx4BskQPYVGcIIST+jEzIIThJ+Kp4dB1JOHB
PKbypA0JgASNDg==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <87tt5sjx97.fsf@HIDDEN> (rutherther@HIDDEN's message of
"Sat, 10 May 2025 17:33:56 +0200")
References: <87tt5sjx97.fsf@HIDDEN>
Date: Wed, 14 May 2025 22:33:09 +0200
Message-ID: <874ixnyltm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.3 (/)
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.3 (-)
Hi,
Rutherther <rutherther@HIDDEN> writes:
> There are reports from users with inconsistencies in ownership, it seems =
that at
> least /var/guix is sometimes left with wrong owner, but maybe even parts
> of the store? I cannot verify that.
Would be nice to get their reports here, otherwise we=E2=80=99re left
speculating.
> The guix-ownership service checks /gnu/store ownership to check if the
> whole store and all files important for the daemon (/etc/guix,
> /var/guix) are owned by the appropriate user.
>
> If the folder isn't owned by appropriate user, it moves to those steps:
> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
> itself as last step
> 2. Fix /var/guix
> 3. Fix /etc/guix
> 4. Fix /var/log/guix
>
> So from those laid out steps it should be obvious that if guix-ownership
> service somehow stops between steps 1 and 2, it will never recover
> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
> change owner as last.
Well, the fundamental assumption is that =E2=80=98guix-ownership=E2=80=99 i=
s not
interrupted during its work; manual intervention is needed to repair
things if it is interrupted.
I don=E2=80=99t see any way around that but perhaps we should warn about it=
more
clearly?
> On the other hand it feels much of a coincidence users would be
> consistently hitting reboots between those steps. So maybe I am
> overlooking another thing. I checked the file-system-fold, it goes to
> /gnu/store as last, so that would mean putting step 1 after 4 should fix
> that. Still, maybe only /gnu/store itself should be skipped instead of mo=
ving
> the step, and done as last, step 5 to ensure it's fine even if
> file-system-fold somehow changed the ordering? Not sure how exactly it
> should behave in that regard.
Doing /gnu/store last is a good idea because it reduces the window
during which the inconsistent state could go undetected.
Feel free to propose a patch; otherwise I=E2=80=99ll give it a try, but not
before next week.
Thanks,
Ludo=E2=80=99.
X-Loop: help-debbugs@HIDDEN
Subject: bug#78355: guix-ownership inconsistent state
Resent-From: Rutherther <rutherther@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Thu, 15 May 2025 07:37:02 +0000
Resent-Message-ID: <handler.78355.B78355.174729456810686 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78355
X-GNU-PR-Package: guix
X-GNU-PR-Keywords:
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: 78355 <at> debbugs.gnu.org, Ben Sturmfels <ben@HIDDEN>
Received: via spool by 78355-submit <at> debbugs.gnu.org id=B78355.174729456810686
(code B ref 78355); Thu, 15 May 2025 07:37:02 +0000
Received: (at 78355) by debbugs.gnu.org; 15 May 2025 07:36:08 +0000
Received: from localhost ([127.0.0.1]:50558 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uFT8R-0002mH-Jc
for submit <at> debbugs.gnu.org; Thu, 15 May 2025 03:36:08 -0400
Received: from ditigal.xyz ([78.46.201.50]:38632 helo=mail.ditigal.xyz)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <rutherther@HIDDEN>)
id 1uFT8N-0002lh-FB
for 78355 <at> debbugs.gnu.org; Thu, 15 May 2025 03:36:04 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 8f4ffda0
(TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO);
Thu, 15 May 2025 07:35:55 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
In-Reply-To: <874ixnyltm.fsf@HIDDEN>
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
Date: Thu, 15 May 2025 09:35:52 +0200
Message-ID: <87msbeuy07.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
i=@ditigal.xyz; q=dns/txt; s=20240917; t=1747294555; h=from : to : cc
: subject : in-reply-to : references : date : message-id :
mime-version : content-type : content-transfer-encoding : from;
bh=PSQE5fxFU4EW0P4eFXRrTcL74tpCBV6QaRg9M5D8k5w=;
b=OvA6V7NkQLypnkew9e6UjdQMRNgAxx5quptk669ZzeKcfdZepEjHaSpG8gxSI8GwAR5N6
Lg3vpWu3Ob2VWuJX4TXGpbNWCzz6uzAMZOaSd5JAZXCp51w9xsCey6ZarvoYwrNTgKSdLD/
q7hasIYQEFmsoThsdnA1QSSeuUQxZS0=
X-Spam-Score: 2.5 (++)
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: Hi Ben,
I am CCing you to get more information about the inconsistent
ownership, if you could help with that. The most important questions are
probably: 0. Are you sure the service actually ran after you reconfigured
to root? It should definitely run after reboot, not sure if after reconfigure
as the service [...]
Content analysis details: (2.5 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.46.201.50 listed in sa-accredit.habeas.com]
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.46.201.50 listed in bl.score.senderscore.com]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
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: 2.5 (++)
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: Hi Ben, I am CCing you to get more information about the inconsistent
ownership, if you could help with that. The most important questions are
probably: 0. Are you sure the service actually ran after you reconfigured
to root? It should definitely run after reboot, not sure if after reconfigure
as the service [...]
Content analysis details: (2.5 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.46.201.50 listed in sa-accredit.habeas.com]
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.46.201.50 listed in bl.score.senderscore.com]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Hi Ben,
I am CCing you to get more information about the inconsistent ownership,
if you could help with that.
The most important questions are probably:
0. Are you sure the service actually ran after you reconfigured to root?
It should definitely run after reboot, not sure if after reconfigure
as the service already exists, it's just modified
1. Do you think you could've killed the service when it was running
after you reconfigured back to privileged daemon, ie. by rebooting when
it was running?
2. Do you know what folders had wrong owners?
- Was everything under /var/guix fully owned by 971?
- Was everything under /etc/guix fully owned by 971?
- Was everything under store fully owned by 971?
Hi Ludo,
Ludovic Court=C3=A8s <ludo@HIDDEN> writes:
> Hi,
>
> Rutherther <rutherther@HIDDEN> writes:
>
>> There are reports from users with inconsistencies in ownership, it seems=
that at
>> least /var/guix is sometimes left with wrong owner, but maybe even parts
>> of the store? I cannot verify that.
>
> Would be nice to get their reports here, otherwise we=E2=80=99re left
> speculating.
I am afraid we will be left speculating either way, that's why I chose
this approach. That is because none of the users I know of took time to
debug it and just fixed it. CCing Ben Sturmfels who
encountered it (see
https://lists.gnu.org/archive/html/help-guix/2025-05/msg00052.html).
For the other user I know of, I don't know their e-mail.
Note that on IRC I recommended the user to chown $USER /gnu/store
($USER just cause it's easiest, any non-root user would be fine) and
herd start guix-ownership and that fixed the issue. So the service
definitely is doing its job. See here https://logs.guix.gnu.org/guix/2025-0=
5-10.log#171215
>
>> The guix-ownership service checks /gnu/store ownership to check if the
>> whole store and all files important for the daemon (/etc/guix,
>> /var/guix) are owned by the appropriate user.
>>
>> If the folder isn't owned by appropriate user, it moves to those steps:
>> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
>> itself as last step
>> 2. Fix /var/guix
>> 3. Fix /etc/guix
>> 4. Fix /var/log/guix
>>
>> So from those laid out steps it should be obvious that if guix-ownership
>> service somehow stops between steps 1 and 2, it will never recover
>> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
>> change owner as last.
>
> Well, the fundamental assumption is that =E2=80=98guix-ownership=E2=80=99=
is not
> interrupted during its work; manual intervention is needed to repair
> things if it is interrupted.
I think it would at least be good if there was a script to do what
guix-ownership does, but force it without the /gnu/store ownership
check, to make it easier for users to recover. Maybe even an optional argum=
ent to
guix-ownership, where you could `sudo herd start guix-ownership 1` and
that would force the chown'ing?
>
> I don=E2=80=99t see any way around that but perhaps we should warn about =
it more
> clearly?
That would definitely be great, I think you can easily oversee that the
service has started. Now I am not sure if one-shot services are started
after change when you reconfigure, if they are, I think it's going to be
a common issue - people reconfigure & reboot! Meaning they will usually
stop the service, or am I mistaken here?
>
>> On the other hand it feels much of a coincidence users would be
>> consistently hitting reboots between those steps. So maybe I am
>> overlooking another thing. I checked the file-system-fold, it goes to
>> /gnu/store as last, so that would mean putting step 1 after 4 should fix
>> that. Still, maybe only /gnu/store itself should be skipped instead of m=
oving
>> the step, and done as last, step 5 to ensure it's fine even if
>> file-system-fold somehow changed the ordering? Not sure how exactly it
>> should behave in that regard.
>
> Doing /gnu/store last is a good idea because it reduces the window
> during which the inconsistent state could go undetected.
I think it completely removes it. Or why do you think not?
If it really doesn't I think it would be good if we came up with an
approach that would remove this window. The best way to achieve no
inconsistence-window would be to just check all of the permissions, but
that's probably an overkill.
For example creating a 'stamp'
somewhere that says it was done, at the end, and checking if that stamp
file matches what we expect.
>
> Feel free to propose a patch; otherwise I=E2=80=99ll give it a try, but n=
ot
> before next week.
>
> Thanks,
> Ludo=E2=80=99.
Thanks
Rutherther
X-Loop: help-debbugs@HIDDEN
Subject: bug#78355: guix-ownership inconsistent state
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 May 2025 08:34:02 +0000
Resent-Message-ID: <handler.78355.B78355.174729800021700 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78355
X-GNU-PR-Package: guix
X-GNU-PR-Keywords:
To: Rutherther <rutherther@HIDDEN>
Cc: 78355 <at> debbugs.gnu.org, Ben Sturmfels <ben@HIDDEN>
Received: via spool by 78355-submit <at> debbugs.gnu.org id=B78355.174729800021700
(code B ref 78355); Thu, 15 May 2025 08:34:02 +0000
Received: (at 78355) by debbugs.gnu.org; 15 May 2025 08:33:20 +0000
Received: from localhost ([127.0.0.1]:50882 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uFU1o-0005du-1s
for submit <at> debbugs.gnu.org; Thu, 15 May 2025 04:33:20 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:56652)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uFU1l-0005dU-5c
for 78355 <at> debbugs.gnu.org; Thu, 15 May 2025 04:33:17 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
id 1uFU1e-00047I-Nm; Thu, 15 May 2025 04:33:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
From; bh=edU64oEbDD8LrkXp/KSZ8xl64Nu6IOEr7xSF4+dhBFo=; b=af6NZsvdHU26bF0L8j1Q
5x0kFMsEYo+n2Mhpyz9nprVPNByadtscNR+1sldB3r/EooGj6TAc7TDwdE8EM+ZVmXG0h4kNg+mqx
/qSaqZ6p61fGIiCfgQDQNmBS7DPkNCtUM79LUpB8p+fh9sZBetjdr8uGKMe5ecNJNt9wiZmWDWK14
dhepZZVo2tCB5nDgpUumozLJSTa8QeFl52frtFdtGu9kyaeDm7oqEoaZT7AysP6ghDiPINNnAGKQw
HxAfni1Uh6gTyncIow1UmNzIqr4L3NP1F2oI2NZMWwdR711uZXBgN1msPMR69D1dB1hfXjASjhbpk
az2HY58mQAZ3bg==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <87msbeuy07.fsf@HIDDEN> (rutherther@HIDDEN's message of
"Thu, 15 May 2025 09:35:52 +0200")
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
<87msbeuy07.fsf@HIDDEN>
User-Agent: mu4e 1.12.9; emacs 29.4
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Sextidi 26 =?UTF-8?Q?Flor=C3=A9al?= an 233 de la
=?UTF-8?Q?R=C3=A9volution,?= jour du Fusain
Date: Thu, 15 May 2025 10:20:27 +0200
Message-ID: <87ecwqxp2s.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.3 (/)
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.3 (-)
Hi,
Rutherther <rutherther@HIDDEN> writes:
> I think it would at least be good if there was a script to do what
> guix-ownership does, but force it without the /gnu/store ownership
> check, to make it easier for users to recover. Maybe even an optional arg=
ument to
> guix-ownership, where you could `sudo herd start guix-ownership 1` and
> that would force the chown'ing?
There=E2=80=99s +/- a script in the manual (info "(guix) Build Environment
Setup").
>>
>> I don=E2=80=99t see any way around that but perhaps we should warn about=
it more
>> clearly?
>
> That would definitely be great, I think you can easily oversee that the
> service has started. Now I am not sure if one-shot services are started
> after change when you reconfigure, if they are, I think it's going to be
> a common issue - people reconfigure & reboot! Meaning they will usually
> stop the service, or am I mistaken here?
The one-shot service is restarted upon reconfigure, but one also has to
restart guix-daemon in this case.
>> Doing /gnu/store last is a good idea because it reduces the window
>> during which the inconsistent state could go undetected.
>
> I think it completely removes it. Or why do you think not?
Yes, you=E2=80=99re right, as long as /gnu/store itself is done last.
Ludo=E2=80=99.
X-Loop: help-debbugs@HIDDEN
Subject: bug#78355: guix-ownership inconsistent state
Resent-From: Ben Sturmfels <ben@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 30 May 2025 09:32:01 +0000
Resent-Message-ID: <handler.78355.B78355.17485974664274 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78355
X-GNU-PR-Package: guix
X-GNU-PR-Keywords:
To: Rutherther <rutherther@HIDDEN>
Cc: 78355 <at> debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Received: via spool by 78355-submit <at> debbugs.gnu.org id=B78355.17485974664274
(code B ref 78355); Fri, 30 May 2025 09:32:01 +0000
Received: (at 78355) by debbugs.gnu.org; 30 May 2025 09:31:06 +0000
Received: from localhost ([127.0.0.1]:45882 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uKw4v-00016q-7T
for submit <at> debbugs.gnu.org; Fri, 30 May 2025 05:31:06 -0400
Received: from fhigh-b4-smtp.messagingengine.com ([202.12.124.155]:35321)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ben@HIDDEN>) id 1uKw4N-000146-Ej
for 78355 <at> debbugs.gnu.org; Fri, 30 May 2025 05:30:32 -0400
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
[10.202.2.45])
by mailfhigh.stl.internal (Postfix) with ESMTP id 790A4254016F;
Fri, 30 May 2025 05:30:25 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
by phl-compute-05.internal (MEProxy); Fri, 30 May 2025 05:30:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sturm.com.au; h=
cc:cc:content-type:content-type:date:date:from:from:in-reply-to
:in-reply-to:message-id:mime-version:references:reply-to:subject
:subject:to:to; s=fm3; t=1748597425; x=1748683825; bh=ZqUEXZ3Wyu
5EHyFkJgbs7wz/efWxhrT0V0xSeRZv2ZQ=; b=ZjxNM5hHkCSwLLlOTMDYWO7XFd
tb5tprngN+n6ar4ggAPBHHY0af/orzgQMNllhkqFNlwCo1avBJiMQ9alHDm7MCPU
VYYXrgGWrEi/3H08YRRHrXb5Aa2GRPs9WeT0u8bLH8zEs/qLnWL+TqQVEkfgaJQp
we/JQjza8GpKYv6uFUUKl5ndbkSBRWJR3ybIY/rRa2Rvqv43nNGPxUDeqUl73YL7
MNMy88nNBx5Bz6H97ZR2pQ8IFM/E+bo/CwQLvowOp353EzNpoUWXsvj4gflkdwZk
pkrGbc6Vao1uZ01J/NfcwgIhS0vJwMVyeHwv8gDdyZ1yBjEtomrsrU0EPGyA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-type:content-type:date:date
:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
:message-id:mime-version:references:reply-to:subject:subject:to
:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
1748597425; x=1748683825; bh=ZqUEXZ3Wyu5EHyFkJgbs7wz/efWxhrT0V0x
SeRZv2ZQ=; b=Fukkhi8wguoXqNhxvb8dEuBbNEMXf3OQCZGzRBYsoHncEDOQL0X
bCwfJUiwbpP5PS0CHZRv7iLqKHpyGlfUPEeKSYhTsX7SOXiQ+iUiLp5/xV3A1qwa
qutmDhD1L/PjozvNYLTfRD2TNCbn+zIIVoKZdh2A5Vzyi+FPViFpZZYIhTyzKlbU
sWYBz2hSZbEXhCIa1scK6p5cJ+cauJKRqYOwsX8IkVwJ33eJrOLdoPdMPC1s7VdB
rQA8nseXh5OWfHlVwxUpAo6b9U+vqLoQDplhTPDFSCei/t7H//NlhzIvfOGz4A6u
Lg75VtX0s2GqZl7hCaNnsf5O+elMFZ1GRtw==
X-ME-Sender: <xms:sXo5aBmOgLXlrcthHcqMuzX6k7P7UzF3carbtqlTvtBBWCVu6UB2gA>
<xme:sXo5aM0SabyK30P-7SXCmv0hZwTSVQTBGaYzUw9uPalouL_vXEb5xOxfn8OMfiAhq
MYykJtO8OBbYuY>
X-ME-Received: <xmr:sXo5aHqH_bEZ-K00NnbtSbsiTJ5U7miZDPSYnTukFAASGWZVepYVwlT-Q6Wh>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvkeeiieculddtuddrgeefvddrtd
dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhgf
fffkgggtsehttdertddtredtnecuhfhrohhmpeeuvghnucfuthhurhhmfhgvlhhsuceosg
gvnhesshhtuhhrmhdrtghomhdrrghuqeenucggtffrrghtthgvrhhnpeehjeehudefgeeh
feetvdeggfevlefhteegfeeigeefgeejvdejfeevuefgjeelieenucevlhhushhtvghruf
hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsvghnsehsthhurhhmrdgtohhm
rdgruhdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoh
eplhhuughosehgnhhurdhorhhgpdhrtghpthhtoheprhhuthhhvghrthhhvghrseguihht
ihhgrghlrdighiiipdhrtghpthhtohepjeekfeehheesuggvsggsuhhgshdrghhnuhdroh
hrgh
X-ME-Proxy: <xmx:sXo5aBm3BYZN-f1trykw7exUkm9BjZ4JHn4adxaZcFop6vQmkZZWpA>
<xmx:sXo5aP0vP-go25z2Qtc-CFp9WLeTX9TD-W5zT9pL7TGEvER-J9sy7A>
<xmx:sXo5aAtZJ8zanSMMpTcAhLhrueDolhe57u539aRPehtl1T9XFJZoWw>
<xmx:sXo5aDVdglnLmAdq4M0vCQD6tZLinwIFessApquasXwClUAQsINB4w>
<xmx:sXo5aG-dHp5HiSqYOME29LnDEmv2jy-_c5BujHy-7I5zXl_YlgIiLGUP>
Feedback-ID: i7bb0428e:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
30 May 2025 05:30:23 -0400 (EDT)
Received: from Marseille (localhost.lan [127.0.0.1])
by localhost (OpenSMTPD) with ESMTP id aab3957b;
Fri, 30 May 2025 09:30:21 +0000 (UTC)
From: Ben Sturmfels <ben@HIDDEN>
In-Reply-To: <87msbeuy07.fsf@HIDDEN> (rutherther@HIDDEN's message of
"Thu, 15 May 2025 09:35:52 +0200")
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
<87msbeuy07.fsf@HIDDEN>
User-Agent: mu4e 1.12.11; emacs 30.0.92
Date: Fri, 30 May 2025 19:30:21 +1000
Message-ID: <874ix2qwcy.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
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: (CCing the bug tracker) Hi Ruther, Thanks for all your work
and help on this issue! Sorry for the delay - I needed to find a quiet time
to reconfigure and watch what happens more carefully.
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[202.12.124.155 listed in sa-trusted.bondedsender.org]
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[202.12.124.155 listed in bl.score.senderscore.com]
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[202.12.124.155 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [202.12.124.155 listed in list.dnswl.org]
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 (/)
(CCing the bug tracker)
Hi Ruther,
Thanks for all your work and help on this issue! Sorry for the
delay - I
needed to find a quiet time to reconfigure and watch what happens
more
carefully.
Rutherther <rutherther@HIDDEN> writes:
> I am CCing you to get more information about the inconsistent
> ownership,
> if you could help with that.
>
> The most important questions are probably:
> 0. Are you sure the service actually ran after you reconfigured
> to root?
> It should definitely run after reboot, not sure if after
> reconfigure
> as the service already exists, it's just modified
To be honest, I had no understanding of how the change was taking
place. I
read about it briefly in the `guix pull --news --details` and may
have
briefly referred to the manual - I can't recall exactly. Possibly
naive of
me.
I'll give it another shot now. I've set "privileged? #f" again and
run
"system reconfigure". I see that it prints:
...
building
/gnu/store/yyn762lwzra0nqrrwhgbwwlz2k0qyn0h-upgrade-shepherd-services.scm.drv...
shepherd: Starting service host-name...
shepherd: Service host-name started.
shepherd: Service host-name running with value "Marseille".
shepherd: Service host-name has been started.
shepherd: Starting service user-homes...
shepherd: Service user-homes has been started.
shepherd: Starting service sysctl...
shepherd: Service sysctl has been started.
Then appears to hang, though I now realise that it's busy updating
ownership. Unfortunately there is no feedback to the user or
advice not to
interrupt the process. I watched the ownership in /gnu/store be
progressively updated to "guix-daemon".
It took about 5 mins, then quickly printed:
shepherd: Service user-homes has been started.
shepherd: Starting service guix-ownership...
shepherd: Changing to unprivileged guix-daemon.
shepherd: Service guix-ownership has been started.
shepherd: Starting service x11-socket-directory...
shepherd: Service x11-socket-directory has been started.
shepherd: Service user-homes has been started.
shepherd: Service tor is currently disabled.
shepherd: Service user-homes has been started.
...
The message "Changing to unprivileged guix-daemon" needs to be
visible
before the work is done though. Is it possible that stdout is
being
buffered?
> 1. Do you think you could've killed the service when it was
> running
> after you reconfigured back to privileged daemon, ie. by
> rebooting when
> it was running?
Absolutely I could have killed it - to me it just looks like
reconfigure
had locked up for some reason. I'd probably forgotten that I even
set the
"privileged?" option, or didn't consider the pause might be
related.
So yes, user error on my part, but reflecting on it, the mental
model I
have of Guix is that it's immune to issues such as power outages
during
upgrades. I realise now that this is a complex migration, so I
appreciate
that there's some state to manage and it takes time.
Possibly the uprivileged transition might need to be either:
a. more obvious to the user, eg. red text and interactive: "The
migration
to the unprivileged daemon needs to update a very large number of
files and
must not be interrupted. Do not proceed on battery power. Proceed?
(y/N)"
b. robust to being interrupted part way, such as starting the
daemon as
privileged unless the transition process ran successfully. Maybe
that's not
technically feasible though - just a thought.
> 2. Do you know what folders had wrong owners?
> - Was everything under /var/guix fully owned by 971?
> - Was everything under /etc/guix fully owned by 971?
> - Was everything under store fully owned by 971?
Not everything, just some. I'm not 100% sure it was 971, but
something like
that - the ID of a user that didn't exist on the system
(presumably because
I rolled back/reconfigured to "privileged? #t" again).
Now that it's run successfully, all of /gnu/store and /etc/guix
are
guix-daemon:guix-daemon. All of /var/guix is
guix-daemon:guix-daemon except
for files /var/guix/profiles and /var/guix/userpool, which are
root:root.
I haven't rebooted yet, but if you don't hear back from me, assume
that
worked fine.
Thanks again for all your work!
Ben
X-Loop: help-debbugs@HIDDEN
Subject: bug#78355: guix-ownership inconsistent state
Resent-From: Ben Sturmfels <ben@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Fri, 30 May 2025 12:30:02 +0000
Resent-Message-ID: <handler.78355.B78355.17486081971263 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78355
X-GNU-PR-Package: guix
X-GNU-PR-Keywords:
To: Rutherther <rutherther@HIDDEN>
Cc: 78355 <at> debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Received: via spool by 78355-submit <at> debbugs.gnu.org id=B78355.17486081971263
(code B ref 78355); Fri, 30 May 2025 12:30:02 +0000
Received: (at 78355) by debbugs.gnu.org; 30 May 2025 12:29:57 +0000
Received: from localhost ([127.0.0.1]:47206 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uKys0-0000KG-ST
for submit <at> debbugs.gnu.org; Fri, 30 May 2025 08:29:57 -0400
Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:56601)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ben@HIDDEN>) id 1uKyrx-0000Jb-Qi
for 78355 <at> debbugs.gnu.org; Fri, 30 May 2025 08:29:54 -0400
Received: from phl-compute-08.internal (phl-compute-08.phl.internal
[10.202.2.48])
by mailfhigh.phl.internal (Postfix) with ESMTP id 957B81140195;
Fri, 30 May 2025 08:29:48 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
by phl-compute-08.internal (MEProxy); Fri, 30 May 2025 08:29:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sturm.com.au; h=
cc:cc:content-type:content-type:date:date:from:from:in-reply-to
:in-reply-to:message-id:mime-version:references:reply-to:subject
:subject:to:to; s=fm3; t=1748608188; x=1748694588; bh=cybazaI7XZ
/Y81E0APv+SbEFy+KhaNVgo9kcpEmQNwo=; b=WXnlKl5aEb8RHmaFZb73/UnXGf
/h1i+Vy0sIyuaWQMF4qa0bvOrB1rjrzrnpklKskGBYkB7/sKbb4g2apOYSqMIqnA
/h6Kvh15w3t0OqRPtc/He4w+Dr49JxLUv66XFm5u28tOJnuMrMzly6In3eOXagy0
FuWaDC9swwkQa0TkRFfI2F5A52RsWsDz+/7XRKon7SByrU5nfkQTWw0C7dmxQJtj
ASbNHvGstZ866SBm1titW3Ij6Ge9nBOmQ0OytIoRsLmnyvMmeCiMCldpx2Glvrf1
2GujaPnkS64ylkJ+lqfadADBGsmfdczc0VKnmESqMpLzzW8fnB+kFO8iOZZg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-type:content-type:date:date
:feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
:message-id:mime-version:references:reply-to:subject:subject:to
:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
1748608188; x=1748694588; bh=cybazaI7XZ/Y81E0APv+SbEFy+KhaNVgo9k
cpEmQNwo=; b=DvVNRV/KQsNeQbsuXFzsfEBT+wBvPUiRLt/VuAnvKBp8hSoht9O
dbN30R/bPaqZGjQGuH5Fw6IruQvpNM6z68IWr9CPjcRVYs9Cxw27co1JRYt2pU9e
YnAGLP4SYJy/nzVFA8bazt2ryY69cL49EYvfxeqxYMAsjCMgB/dURtbEoGhAjYBM
wHEus5vtptvnRflElYrmFHtHlbc9nSrzX1EQiw+wd0/yRvP9JnCns7QK7YgNgzDi
JD7e6ZYT3p7QTXI9cE6K3x2m+s9JlWEV6qY7gIGZwurGnCqc5l3ILXpWg3Wz2H9w
AZjaemO0uL76iBv+RpOV/O8xExjSVC1JhWQ==
X-ME-Sender: <xms:vKQ5aLqNUlEGs1p3Co_uEAvfmeHErBMdWl4qnpK_et6vhdjmDGpDFw>
<xme:vKQ5aFqQ6QbrlVIsTLLaNz3zJQ8Z_VrYkWfAHH-Ac6de1LAwAbqk6AuCyK-oe9erv
2Jc8nxXx6e9izA>
X-ME-Received: <xmr:vKQ5aIOqe98utSAWtmy0h8k1HpyAimZbzRCgxlLUaZGMoJMOZusl3KZNBlh58YuJva_GfJcOzyv8KGZ89ojVsUA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvledtvdculddtuddrgeefvddrtd
dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhgf
fffkgggtsehttdertddtredtnecuhfhrohhmpeeuvghnucfuthhurhhmfhgvlhhsuceosg
gvnhesshhtuhhrmhdrtghomhdrrghuqeenucggtffrrghtthgvrhhnpeeifefhueetgfdv
vefgvdehffeiieehkeekgeffjeetvdffkeduvdeghfefhfeileenucffohhmrghinhepgh
hnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
ohhmpegsvghnsehsthhurhhmrdgtohhmrdgruhdpnhgspghrtghpthhtohepfedpmhhoug
gvpehsmhhtphhouhhtpdhrtghpthhtohepjeekfeehheesuggvsggsuhhgshdrghhnuhdr
ohhrghdprhgtphhtthhopehluhguohesghhnuhdrohhrghdprhgtphhtthhopehruhhthh
gvrhhthhgvrhesughithhighgrlhdrgiihii
X-ME-Proxy: <xmx:vKQ5aO63gFJZJQGfhVd5zZd9GxYTIT1cbDX6I9gHxf3-M1oYozrw8g>
<xmx:vKQ5aK7oufWzQGMFUfIfMThyP-dFhsOaCRJpDiFcVXyYpZtudjAz1Q>
<xmx:vKQ5aGgCg4xudjmZuYyHGv0TYLaJIQo7dx0tDdKoxoTcMX2Ys69ylA>
<xmx:vKQ5aM4Hb2ILWQPoUquJ2k4HkQ14H1v_z9Vw2iiqjtCo3Ro0QloZGA>
<xmx:vKQ5aHSRsmY9rJIGJAzeBeepuWbguBMiTGUrX3s8zlr5gMJwwrQC_13r>
Feedback-ID: i7bb0428e:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
30 May 2025 08:29:46 -0400 (EDT)
Received: from Marseille (localhost [127.0.0.1])
by localhost (OpenSMTPD) with ESMTP id 8f44b4fb;
Fri, 30 May 2025 12:29:42 +0000 (UTC)
From: Ben Sturmfels <ben@HIDDEN>
In-Reply-To: <874ix2qwcy.fsf@HIDDEN> (Ben Sturmfels's message of "Fri,
30 May 2025 19:30:21 +1000")
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
<87msbeuy07.fsf@HIDDEN> <874ix2qwcy.fsf@HIDDEN>
User-Agent: mu4e 1.12.11; emacs 30.0.92
Date: Fri, 30 May 2025 22:29:37 +1000
Message-ID: <874ix2uvri.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
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 (-)
Ben Sturmfels <ben@HIDDEN> writes:
> Now that it's run successfully, all of /gnu/store and /etc/guix
> are
> guix-daemon:guix-daemon. All of /var/guix is
> guix-daemon:guix-daemon except
> for files /var/guix/profiles and /var/guix/userpool, which are
> root:root.
>
> I haven't rebooted yet, but if you don't hear back from me,
> assume that
> worked fine.
After rebooting, I didn't get any WiFi, but that was expected due
to
https://issues.guix.gnu.org/78047. I think this is primarily what
was
causing me problems originally.
I ran `guix system roll-back`, which completed nearly
instantly. After
rebooting I could see that the "guix-ownership" process was
running in the
background busily changing ownership back to root:root. Once that
was
completed I ran `sudo herd restart NetworkManager` which gave me
WiFi
again.
All seems to be working as intended. I didn't test
rebooting/interrupting
the guix-ownership process part way through. Ideally it would
retry I
guess?
Regards,
Ben
X-Loop: help-debbugs@HIDDEN
Subject: bug#78355: guix-ownership inconsistent state
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: Tue, 10 Jun 2025 13:50:05 +0000
Resent-Message-ID: <handler.78355.B78355.174956336416682 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78355
X-GNU-PR-Package: guix
X-GNU-PR-Keywords:
To: Rutherther <rutherther@HIDDEN>
Cc: 78355 <at> debbugs.gnu.org
Received: via spool by 78355-submit <at> debbugs.gnu.org id=B78355.174956336416682
(code B ref 78355); Tue, 10 Jun 2025 13:50:05 +0000
Received: (at 78355) by debbugs.gnu.org; 10 Jun 2025 13:49:24 +0000
Received: from localhost ([127.0.0.1]:37756 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uOzLs-0004KY-Pw
for submit <at> debbugs.gnu.org; Tue, 10 Jun 2025 09:49:23 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:51262)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uOzLn-0004Ih-7K
for 78355 <at> debbugs.gnu.org; Tue, 10 Jun 2025 09:49:17 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
id 1uOzLh-0000WV-C4; Tue, 10 Jun 2025 09:49:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
From; bh=OjfvUlS/ORqPCHU+6EbCuKDqf8pVOxl2a9H/ZqsT+Es=; b=CnmMgiLgN0SE6tJbSU36
JzV0XMMuK3vmfOBFM2yCyAGFrGwyBewDsU1ijntVmXy+CHXwrU8ODme1mNYyG/i0JqL+lUjEhsZzS
DQT8gJoUB+yzTdIkNAUsGCtqDOL4ffJ/+past6eDGMlDnvLBLU7HDjpSVjotociCOz5z/asLvh4tm
ICOeuS6LBynf6wWxe2HQrSKy2/AkNMkkU/aIx/hKiujksTX06MwDGzugaBLpUO5Ru/X+ztzvBL7hL
uZ9GUBvnlsdl/aN5ltoQ7SA9Et4YaLYJUur7eGZp02Y7rltqHJfKj8d5BZhGNozb3qS40oG9Y7Wgm
Htu/0JXzjwx1sA==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <87tt5sjx97.fsf@HIDDEN> (rutherther@HIDDEN's message of
"Sat, 10 May 2025 17:33:56 +0200")
References: <87tt5sjx97.fsf@HIDDEN>
User-Agent: mu4e 1.12.11; emacs 29.4
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Duodi 22 Prairial an 233 de la =?UTF-8?Q?R=C3=A9volution,?= jour de la Camomille
Date: Tue, 10 Jun 2025 15:48:46 +0200
Message-ID: <87h60niu69.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.3 (/)
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.3 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Rutherther,
Rutherther <rutherther@HIDDEN> writes:
> The guix-ownership service checks /gnu/store ownership to check if the
> whole store and all files important for the daemon (/etc/guix,
> /var/guix) are owned by the appropriate user.
>
> If the folder isn't owned by appropriate user, it moves to those steps:
> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
> itself as last step
> 2. Fix /var/guix
> 3. Fix /etc/guix
> 4. Fix /var/log/guix
>
> So from those laid out steps it should be obvious that if guix-ownership
> service somehow stops between steps 1 and 2, it will never recover
> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
> change owner as last.
Sorry for dropping the ball. How about the patch below?
Note that it would only help if the user retries to change ownership in
the same direction after interrupting the service; ownership change
remains fundamentally non-atomic so it=E2=80=99s still possible to end up i=
n a
partially chown=E2=80=99d state, if one insists.
Thanks,
Ludo=E2=80=99.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index edc6f45850..c2851ef1a9 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -1997,10 +1997,9 @@ (define (guix-ownership-change-program)
lstat))
(define (claim-data-ownership uid gid)
- (format #t "Changing file ownership for /gnu/store \
+ (format #t "Changing file ownership for ~a \
and data directories to ~a:~a...~%"
- uid gid)
- (change-ownership #$(%store-prefix) uid gid)
+ #$(%store-prefix) uid gid)
(let ((excluded '("." ".." "profiles" "userpool")))
(for-each (lambda (directory)
(change-ownership (in-vicinity "/var/guix" directory)
@@ -2012,7 +2011,11 @@ (define (guix-ownership-change-program)
(chown "/var/guix" uid gid)
(change-ownership "/etc/guix" uid gid)
(mkdir-p "/var/log/guix")
- (change-ownership "/var/log/guix" uid gid))
+ (change-ownership "/var/log/guix" uid gid)
+
+ ;; Change the store last so that, if this service is interrupted,
+ ;; ownership appears as having yet to be changed.
+ (change-ownership #$(%store-prefix) uid gid))
(match (command-line)
((_ (= string->number (? integer? uid))
--=-=-=--
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Subject: bug#78355: closed (guix-ownership inconsistent state)
CC: tracker <at> debbugs.gnu.org
Message-ID: <handler.78355.D78355.17514089437908.ackdone <at> debbugs.gnu.org>
References: <87h5zvy4b3.fsf@HIDDEN> <87tt5sjx97.fsf@HIDDEN>
X-Gnu-PR-Message: closed 78355
X-Gnu-PR-Package: guix
Date: Tue, 01 Jul 2025 22:30:05 +0000
Content-Type: multipart/mixed; boundary="----------=_1751409005-8440-0"
This is a multi-part message in MIME format...
------------=_1751409005-8440-0
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Your message dated Tue, 01 Jul 2025 23:44:16 +0200
with message-id <87h5zvy4b3.fsf@HIDDEN>
and subject line Re: bug#78355: guix-ownership inconsistent state
has caused the debbugs.gnu.org bug report #78355,
regarding guix-ownership inconsistent state
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs@HIDDEN)
--=20
78355: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78355
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems
------------=_1751409005-8440-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Received: (at submit) by debbugs.gnu.org; 10 May 2025 15:34:23 +0000
Received: from localhost ([127.0.0.1]:48265 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDmDX-00005u-2m
for submit <at> debbugs.gnu.org; Sat, 10 May 2025 11:34:23 -0400
Received: from lists.gnu.org ([2001:470:142::17]:46910)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <rutherther@HIDDEN>)
id 1uDmDU-00005K-Hx
for submit <at> debbugs.gnu.org; Sat, 10 May 2025 11:34:21 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <rutherther@HIDDEN>)
id 1uDmDG-000572-7K
for bug-guix@HIDDEN; Sat, 10 May 2025 11:34:07 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::] helo=mail.ditigal.xyz)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256)
(Exim 4.90_1) (envelope-from <rutherther@HIDDEN>)
id 1uDmDD-0003DM-CF
for bug-guix@HIDDEN; Sat, 10 May 2025 11:34:05 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 66d8be0f
(TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO) for <bug-guix@HIDDEN>;
Sat, 10 May 2025 15:33:58 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
To: bug-guix@HIDDEN
Subject: guix-ownership inconsistent state
X-Debbugs-Cc: ludo@HIDDEN
Date: Sat, 10 May 2025 17:33:56 +0200
Message-ID: <87tt5sjx97.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
i=@ditigal.xyz; q=dns/txt; s=20240917; t=1746891238; h=from : to :
subject : date : message-id : mime-version : content-type : from;
bh=lSlDEuauDctdro3L+96w0wMzsR2FNiLn9f7JIB0Prv0=;
b=U9xGN6LZ3HryBxVYDA8jTv6sDpYiVaH4iurvZw8NUPLRTZYNUmKd4WRnfx26n9tzFQJ8h
nLzfhXwCPbqqMSLquuQ095jCLC3gGAwdmC70DjVojSfznvxAzz0dmYfDQGgg+rIO/XRvGtw
Gr8J8f/yJVSW8HxsDsWoEzBGHJtKTeQ=
Received-SPF: pass client-ip=2a01:4f8:1c1b:6a1c::;
envelope-from=rutherther@HIDDEN; helo=mail.ditigal.xyz
X-Spam_score_int: 4
X-Spam_score: 0.4
X-Spam_bar: /
X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499,
FROM_SUSPICIOUS_NTLD_FP=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 3.4 (+++)
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: There are reports from users with inconsistencies in
ownership,
it seems that at least /var/guix is sometimes left with wrong owner, but
maybe even parts of the store? I cannot verify that. The guix-ownership
service
checks /gnu/store ownership to check if the whole store and all files
important
for the daemon (/etc/guix, /var/guix) are owned by the appropriate user.
Content analysis details: (3.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.9 SPF_FAIL SPF: sender does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
id=rutherther%40ditigal.xyz; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
0.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
X-Debbugs-Envelope-To: submit
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: 2.4 (++)
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: There are reports from users with inconsistencies in ownership,
it seems that at least /var/guix is sometimes left with wrong owner, but
maybe even parts of the store? I cannot verify that. The guix-ownership service
checks /gnu/store ownership to check if the whole store and all files important
for the daemon (/etc/guix, /var/guix) are owned by the appropriate user.
Content analysis details: (2.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2001:470:142:0:0:0:0:17 listed in]
[list.dnswl.org]
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.9 SPF_FAIL SPF: sender does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.org/Why?s=mfrom;id=rutherther%40ditigal.xyz;ip=2001%3A470%3A142%3A%3A17;r=debbugs.gnu.org]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
There are reports from users with inconsistencies in ownership, it seems that at
least /var/guix is sometimes left with wrong owner, but maybe even parts
of the store? I cannot verify that.
The guix-ownership service checks /gnu/store ownership to check if the
whole store and all files important for the daemon (/etc/guix,
/var/guix) are owned by the appropriate user.
If the folder isn't owned by appropriate user, it moves to those steps:
1. Fix permissions in /gnu/store - first under it, then /gnu/store
itself as last step
2. Fix /var/guix
3. Fix /etc/guix
4. Fix /var/log/guix
So from those laid out steps it should be obvious that if guix-ownership
service somehow stops between steps 1 and 2, it will never recover
ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
change owner as last.
On the other hand it feels much of a coincidence users would be
consistently hitting reboots between those steps. So maybe I am
overlooking another thing. I checked the file-system-fold, it goes to
/gnu/store as last, so that would mean putting step 1 after 4 should fix
that. Still, maybe only /gnu/store itself should be skipped instead of moving
the step, and done as last, step 5 to ensure it's fine even if
file-system-fold somehow changed the ordering? Not sure how exactly it
should behave in that regard.
Regards
Rutherther
------------=_1751409005-8440-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Received: (at 78355-done) by debbugs.gnu.org; 1 Jul 2025 22:29:03 +0000
Received: from localhost ([127.0.0.1]:59356 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uWjTJ-00023H-JI
for submit <at> debbugs.gnu.org; Tue, 01 Jul 2025 18:29:02 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:46208)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uWjTF-000227-PH
for 78355-done <at> debbugs.gnu.org; Tue, 01 Jul 2025 18:28:58 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
id 1uWjT9-0006nO-Pm; Tue, 01 Jul 2025 18:28:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
From; bh=33GSnOao+twWdXyzfLDn7PTZSxPrLr9pIAvAcMPRgjE=; b=FSfEReS9869TGLbP0lJi
sUD4nBj/Dj7cPQXhinte+5bJLzQilnt11ecNLyNxq9KnsJ6ywPaja1oFwUp0LYQNcn9eoG/Whf6EJ
RVeZJJqxwvpReGFU8/q3s8MSSDTF4rc0SVdg9NseL0XzR9T2f4HupQJiBX2P0SjWLMCG7G9e1sDan
BEYwM/h54CyorAfmNNeJKtmHEAftNDRc8A6ousTbI+a8WM5A6jqAsiSo+qrW9uXAbZAIm1EuUDIGJ
zoirRgPYwqVCTGT7ftKB5LSsqnyRP572tpmw/6nrHLDqbboVoie0bo6olVJQmuu71t7ysqxrnbzHI
bXeKUqdWG/RDaw==;
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Rutherther <rutherther@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
In-Reply-To: <87h60niu69.fsf@HIDDEN> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
=?utf-8?Q?s?= message of "Tue, 10 Jun 2025 15:48:46 +0200")
References: <87tt5sjx97.fsf@HIDDEN> <87h60niu69.fsf@HIDDEN>
User-Agent: mu4e 1.12.11; emacs 30.1
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Tridi 13 Messidor an 233 de la =?utf-8?Q?R=C3=A9volu?=
=?utf-8?Q?tion=2C?= jour de la =?utf-8?Q?Girofl=C3=A9e?=
Date: Tue, 01 Jul 2025 23:44:16 +0200
Message-ID: <87h5zvy4b3.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.3 (/)
X-Debbugs-Envelope-To: 78355-done
Cc: 78355-done <at> debbugs.gnu.org
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.3 (-)
Hi Rutherther,
Ludovic Court=C3=A8s <ludo@HIDDEN> writes:
> Rutherther <rutherther@HIDDEN> writes:
>
>> The guix-ownership service checks /gnu/store ownership to check if the
>> whole store and all files important for the daemon (/etc/guix,
>> /var/guix) are owned by the appropriate user.
>>
>> If the folder isn't owned by appropriate user, it moves to those steps:
>> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
>> itself as last step
>> 2. Fix /var/guix
>> 3. Fix /etc/guix
>> 4. Fix /var/log/guix
>>
>> So from those laid out steps it should be obvious that if guix-ownership
>> service somehow stops between steps 1 and 2, it will never recover
>> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
>> change owner as last.
>
> Sorry for dropping the ball. How about the patch below?
Pushed as c33bc8008090bafda228e475dedc71cd06f56e4f.
Thanks!
Ludo'.
------------=_1751409005-8440-0--
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Rutherther <rutherther@HIDDEN>
Subject: bug#78355: closed (Re: bug#78355: guix-ownership inconsistent state)
Message-ID: <handler.78355.D78355.17514089437908.notifdone <at> debbugs.gnu.org>
References: <87h5zvy4b3.fsf@HIDDEN> <87tt5sjx97.fsf@HIDDEN>
X-Gnu-PR-Message: they-closed 78355
X-Gnu-PR-Package: guix
Reply-To: 78355 <at> debbugs.gnu.org
Date: Tue, 01 Jul 2025 22:30:06 +0000
Content-Type: multipart/mixed; boundary="----------=_1751409006-8440-1"
This is a multi-part message in MIME format...
------------=_1751409006-8440-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Your bug report
#78355: guix-ownership inconsistent state
which was filed against the guix package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 78355 <at> debbugs.gnu.org.
--=20
78355: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78355
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems
------------=_1751409006-8440-1
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Received: (at 78355-done) by debbugs.gnu.org; 1 Jul 2025 22:29:03 +0000
Received: from localhost ([127.0.0.1]:59356 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uWjTJ-00023H-JI
for submit <at> debbugs.gnu.org; Tue, 01 Jul 2025 18:29:02 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:46208)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uWjTF-000227-PH
for 78355-done <at> debbugs.gnu.org; Tue, 01 Jul 2025 18:28:58 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
id 1uWjT9-0006nO-Pm; Tue, 01 Jul 2025 18:28:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
From; bh=33GSnOao+twWdXyzfLDn7PTZSxPrLr9pIAvAcMPRgjE=; b=FSfEReS9869TGLbP0lJi
sUD4nBj/Dj7cPQXhinte+5bJLzQilnt11ecNLyNxq9KnsJ6ywPaja1oFwUp0LYQNcn9eoG/Whf6EJ
RVeZJJqxwvpReGFU8/q3s8MSSDTF4rc0SVdg9NseL0XzR9T2f4HupQJiBX2P0SjWLMCG7G9e1sDan
BEYwM/h54CyorAfmNNeJKtmHEAftNDRc8A6ousTbI+a8WM5A6jqAsiSo+qrW9uXAbZAIm1EuUDIGJ
zoirRgPYwqVCTGT7ftKB5LSsqnyRP572tpmw/6nrHLDqbboVoie0bo6olVJQmuu71t7ysqxrnbzHI
bXeKUqdWG/RDaw==;
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Rutherther <rutherther@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
In-Reply-To: <87h60niu69.fsf@HIDDEN> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
=?utf-8?Q?s?= message of "Tue, 10 Jun 2025 15:48:46 +0200")
References: <87tt5sjx97.fsf@HIDDEN> <87h60niu69.fsf@HIDDEN>
User-Agent: mu4e 1.12.11; emacs 30.1
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Tridi 13 Messidor an 233 de la =?utf-8?Q?R=C3=A9volu?=
=?utf-8?Q?tion=2C?= jour de la =?utf-8?Q?Girofl=C3=A9e?=
Date: Tue, 01 Jul 2025 23:44:16 +0200
Message-ID: <87h5zvy4b3.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.3 (/)
X-Debbugs-Envelope-To: 78355-done
Cc: 78355-done <at> debbugs.gnu.org
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.3 (-)
Hi Rutherther,
Ludovic Court=C3=A8s <ludo@HIDDEN> writes:
> Rutherther <rutherther@HIDDEN> writes:
>
>> The guix-ownership service checks /gnu/store ownership to check if the
>> whole store and all files important for the daemon (/etc/guix,
>> /var/guix) are owned by the appropriate user.
>>
>> If the folder isn't owned by appropriate user, it moves to those steps:
>> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
>> itself as last step
>> 2. Fix /var/guix
>> 3. Fix /etc/guix
>> 4. Fix /var/log/guix
>>
>> So from those laid out steps it should be obvious that if guix-ownership
>> service somehow stops between steps 1 and 2, it will never recover
>> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
>> change owner as last.
>
> Sorry for dropping the ball. How about the patch below?
Pushed as c33bc8008090bafda228e475dedc71cd06f56e4f.
Thanks!
Ludo'.
------------=_1751409006-8440-1
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Received: (at submit) by debbugs.gnu.org; 10 May 2025 15:34:23 +0000
Received: from localhost ([127.0.0.1]:48265 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDmDX-00005u-2m
for submit <at> debbugs.gnu.org; Sat, 10 May 2025 11:34:23 -0400
Received: from lists.gnu.org ([2001:470:142::17]:46910)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <rutherther@HIDDEN>)
id 1uDmDU-00005K-Hx
for submit <at> debbugs.gnu.org; Sat, 10 May 2025 11:34:21 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <rutherther@HIDDEN>)
id 1uDmDG-000572-7K
for bug-guix@HIDDEN; Sat, 10 May 2025 11:34:07 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::] helo=mail.ditigal.xyz)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256)
(Exim 4.90_1) (envelope-from <rutherther@HIDDEN>)
id 1uDmDD-0003DM-CF
for bug-guix@HIDDEN; Sat, 10 May 2025 11:34:05 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 66d8be0f
(TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO) for <bug-guix@HIDDEN>;
Sat, 10 May 2025 15:33:58 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
To: bug-guix@HIDDEN
Subject: guix-ownership inconsistent state
X-Debbugs-Cc: ludo@HIDDEN
Date: Sat, 10 May 2025 17:33:56 +0200
Message-ID: <87tt5sjx97.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
i=@ditigal.xyz; q=dns/txt; s=20240917; t=1746891238; h=from : to :
subject : date : message-id : mime-version : content-type : from;
bh=lSlDEuauDctdro3L+96w0wMzsR2FNiLn9f7JIB0Prv0=;
b=U9xGN6LZ3HryBxVYDA8jTv6sDpYiVaH4iurvZw8NUPLRTZYNUmKd4WRnfx26n9tzFQJ8h
nLzfhXwCPbqqMSLquuQ095jCLC3gGAwdmC70DjVojSfznvxAzz0dmYfDQGgg+rIO/XRvGtw
Gr8J8f/yJVSW8HxsDsWoEzBGHJtKTeQ=
Received-SPF: pass client-ip=2a01:4f8:1c1b:6a1c::;
envelope-from=rutherther@HIDDEN; helo=mail.ditigal.xyz
X-Spam_score_int: 4
X-Spam_score: 0.4
X-Spam_bar: /
X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499,
FROM_SUSPICIOUS_NTLD_FP=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 3.4 (+++)
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: There are reports from users with inconsistencies in
ownership,
it seems that at least /var/guix is sometimes left with wrong owner, but
maybe even parts of the store? I cannot verify that. The guix-ownership
service
checks /gnu/store ownership to check if the whole store and all files
important
for the daemon (/etc/guix, /var/guix) are owned by the appropriate user.
Content analysis details: (3.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.9 SPF_FAIL SPF: sender does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
id=rutherther%40ditigal.xyz; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
0.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
X-Debbugs-Envelope-To: submit
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: 2.4 (++)
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: There are reports from users with inconsistencies in ownership,
it seems that at least /var/guix is sometimes left with wrong owner, but
maybe even parts of the store? I cannot verify that. The guix-ownership service
checks /gnu/store ownership to check if the whole store and all files important
for the daemon (/etc/guix, /var/guix) are owned by the appropriate user.
Content analysis details: (2.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2001:470:142:0:0:0:0:17 listed in]
[list.dnswl.org]
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.9 SPF_FAIL SPF: sender does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.org/Why?s=mfrom;id=rutherther%40ditigal.xyz;ip=2001%3A470%3A142%3A%3A17;r=debbugs.gnu.org]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
There are reports from users with inconsistencies in ownership, it seems that at
least /var/guix is sometimes left with wrong owner, but maybe even parts
of the store? I cannot verify that.
The guix-ownership service checks /gnu/store ownership to check if the
whole store and all files important for the daemon (/etc/guix,
/var/guix) are owned by the appropriate user.
If the folder isn't owned by appropriate user, it moves to those steps:
1. Fix permissions in /gnu/store - first under it, then /gnu/store
itself as last step
2. Fix /var/guix
3. Fix /etc/guix
4. Fix /var/log/guix
So from those laid out steps it should be obvious that if guix-ownership
service somehow stops between steps 1 and 2, it will never recover
ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
change owner as last.
On the other hand it feels much of a coincidence users would be
consistently hitting reboots between those steps. So maybe I am
overlooking another thing. I checked the file-system-fold, it goes to
/gnu/store as last, so that would mean putting step 1 after 4 should fix
that. Still, maybe only /gnu/store itself should be skipped instead of moving
the step, and done as last, step 5 to ensure it's fine even if
file-system-fold somehow changed the ordering? Not sure how exactly it
should behave in that regard.
Regards
Rutherther
------------=_1751409006-8440-1--
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.