Received: (at 78355) by debbugs.gnu.org; 15 May 2025 08:33:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 15 04:33:20 2025 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: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN> To: Rutherther <rutherther@HIDDEN> Subject: Re: bug#78355: guix-ownership inconsistent state 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=2C?= 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-Debbugs-Envelope-To: 78355 Cc: 78355 <at> debbugs.gnu.org, Ben Sturmfels <ben@HIDDEN> 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.
bug-guix@HIDDEN:bug#78355; Package guix.
Full text available.
Received: (at 78355) by debbugs.gnu.org; 15 May 2025 07:36:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 15 03:36:08 2025
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>
To: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
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-Debbugs-Envelope-To: 78355
Cc: 78355 <at> debbugs.gnu.org, Ben Sturmfels <ben@HIDDEN>
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
bug-guix@HIDDEN:bug#78355; Package guix.
Full text available.Received: (at 78355) by debbugs.gnu.org; 14 May 2025 21:51:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 17:51:38 2025 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: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN> To: Rutherther <rutherther@HIDDEN> Subject: Re: bug#78355: guix-ownership inconsistent state 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-Debbugs-Envelope-To: 78355 Cc: 78355 <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 <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.
bug-guix@HIDDEN:bug#78355; Package guix.
Full text available.
Received: (at submit) by debbugs.gnu.org; 10 May 2025 15:34:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 10 11:34:23 2025
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
Rutherther <rutherther@HIDDEN>:ludo@HIDDEN, bug-guix@HIDDEN.
Full text available.ludo@HIDDEN, bug-guix@HIDDEN:bug#78355; Package guix.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.