Subject: Re: bug#77201: [PATCH] guix: substitute-key-authorization: Fix case when acl symlink is broken
From: Ludovic Courtès <[email-masked]>
To: Rutherther <[email-masked]>
Cc: [email-masked], Ian Eure <[email-masked]>
Date: Mon, 05 May 2025 12:19:21 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

Rutherther <[email-masked]> 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’.