GNU bug report logs - #77201
[PATCH] guix: substitute-key-authorization: Fix case when acl symlink is broken

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#77201: closed ([PATCH] guix: substitute-key-authorization:
 Fix case when acl symlink is broken)
Date: Mon, 05 May 2025 15:36:07 +0000

[Message part 1 (text/plain, inline)]

Your message dated Mon, 05 May 2025 12:19:21 +0200
with message-id <87jz6v5phy.fsf_-_ <at> gnu.org>
and subject line Re: bug#77201: [PATCH] guix: substitute-key-authorization: Fix case when acl symlink is broken
has caused the debbugs.gnu.org bug report #77201,
regarding [PATCH] guix: substitute-key-authorization: Fix case when acl symlink is broken
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
77201: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77201
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Rutherther <rutherther <at> ditigal.xyz>
To: guix-patches <at> gnu.org
Cc: Rutherther <rutherther <at> ditigal.xyz>
Subject: [PATCH] guix: substitute-key-authorization: Fix case when acl symlink
 is broken
Date: Sun, 23 Mar 2025 10:48:28 +0100

One possible solution for an issue when /etc/guix/acl file exists, but points
to a non-existent location. This can for example happen if one is
reinitializing the system, and remove only /gnu/store and /var/guix, keep the
rest okay. This is a major advantage of guix as compared to other distros that
usually need you to reinitialize the whole root partition. But this will leave
the user with acl file pointing to non-existent location. The file-exists?
procedure will return #f for broken symbolic links.

I think that another reason one would get this issue is, if one was booted in
a live iso, chrooted, fixing their system. They would switch generations to
one with different acl file, delete other generations gc rooting the original
acl file and then gc. One could do this approach for example when recovering
from file corruptions in the store, to get rid of the unsubstitutable paths
that can't be repaired with guix gc --verify.

I don't know if there is a better way as I am not that proficient in guile,
but I definitely think this should be fixed and it should be checked if
anything exists in that place, not that the link points to a known location.
Does Guile have a procedure for that that I am missing? If not, shouldn't
we create one in Guix? I can imagine this being a common mistake, where we
want to check if something exists at place 'x', without caring if it's
actually an accessible file. I was looking online and someone made themselves
a function 'file-exists??' that checked basically this what I did here - that
it's either a valid file on the disk, or a broken symlink.

During debugging this issue I also noticed similar issue can occur in special
files and /run/current-system with the .new files that are created with
symlink procedure without checking for their existence. While it's not likely
(especially because the symlink is moved the second it's created)
the user would have /run/current-system.new nor /bin/sh.new etc., I still
think it would be worth fixing to make sure the system can boot even in cases
where something goes horribly wrong.

* gnu/services/base.scm (substitute-key-authorization): Check if acl file is a
(broken) symbolic link

Change-Id: I2f8170606b2f4afeea48f04acfd738b04cafc7cf
---
 gnu/services/base.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 0d2bb31190..e419d043ae 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -1845,7 +1845,7 @@ (define (substitute-key-authorization keys guix)
         ;; If the ACL already exists, move it out of the way.  Create a backup
         ;; if it's a regular file: it's likely that the user manually updated
         ;; it with 'guix archive --authorize'.
-        (if (file-exists? acl-file)
+        (if (or (file-exists? acl-file) (symbolic-link? acl-file))
             (if (and (symbolic-link? acl-file)
                      (store-file-name? (readlink acl-file)))
                 (delete-file acl-file)

base-commit: fbfd2b93831978aadbb96f32cafdab997b04c6c6
prerequisite-patch-id: cf473eb15513404ca1d287f5b7eca109c848203c
prerequisite-patch-id: a46e75bdd193acb5e276e0aa31c77197a3254699
prerequisite-patch-id: a2b4aa0a33d89ee3f6c483aeb71a783cb0e63aa9
-- 
2.49.0

[Message part 3 (message/rfc822, inline)]

From: Ludovic Courtès <ludo <at> gnu.org>
To: Rutherther <rutherther <at> ditigal.xyz>
Cc: 77201-done <at> debbugs.gnu.org, Ian Eure <ian <at> retrospec.tv>
Subject: Re: bug#77201: [PATCH] guix: substitute-key-authorization: Fix case
 when acl symlink is broken
Date: Mon, 05 May 2025 12:19:21 +0200

Hi,

Rutherther <rutherther <at> ditigal.xyz> writes:

> One possible solution for an issue when /etc/guix/acl file exists, but points
> to a non-existent location. This can for example happen if one is
> reinitializing the system, and remove only /gnu/store and /var/guix, keep the
> rest okay. This is a major advantage of guix as compared to other distros that
> usually need you to reinitialize the whole root partition. But this will leave
> the user with acl file pointing to non-existent location. The file-exists?
> procedure will return #f for broken symbolic links.
>
> I think that another reason one would get this issue is, if one was booted in
> a live iso, chrooted, fixing their system. They would switch generations to
> one with different acl file, delete other generations gc rooting the original
> acl file and then gc. One could do this approach for example when recovering
> from file corruptions in the store, to get rid of the unsubstitutable paths
> that can't be repaired with guix gc --verify.
>
> This fixes the issue by looking for type of a file through lstat, instead of
> relying on file-exists?. If the symlink is a broken symlink, it is
> removed. Other than that the old behavior is kept:
> - If regular file, back it up
> - If symlink pointing to the store, remove it
> - If symlink not pointing to the store, back it up
>
> * gnu/services/base.scm (substitute-key-authorization): Check if acl file is a
> (broken) symbolic link
>
> Change-Id: I2f8170606b2f4afeea48f04acfd738b04cafc7cf

Applied after changing the terminology from “broken symlink” to
“dangling symlink”, which I think is more widely used (and easier to
find while grepping!).

Thanks,
Ludo’.

Previous Next

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