bug#38800: Non-existent setuid programs make "guix system reconfigure" break mid-generation-switch

[Jakub Kądziołka]

Steps to reproduce:

0. [IMPORTANT] Make sure you will be able to reconfigure your system
   when all setuid binaries stop working (this includes sudo, which
   makes this, IMHO, a serious bug).

   Namely, either make sure you can log in as root, or keep a "sudo -s"
   shell open. The latter is slightly more dangerous in the event of a
   power outage.

   I would also recommend running "guix pull" in this recovery shell, as
   a root login shell will use root's profile, and not your own.
1. Add a non-existant file to your system configuration's
   setuid-programs. For example,

   (setuid-programs (cons*
                      #~(string-append #$bash "/bin/enoent")
                      %setuid-programs))

2. Reconfigure your system.

   $ sudo guix system reconfigure /etc/config.scm

Actual behavior:

   activating system...
   substitute: updating substitutes from 'https://ci.guix.gnu.org'...  100.0%
   building 
/gnu/store/0ay9wd3wz4x0f5mgmbdfs72w98qvm68z-switch-to-system.scm.drv...
   making '/gnu/store/7vwa2xd378fgwrkgwif7pi6ymshsf2jc-system' the current 
system...
   setting up setuid programs in '/run/setuid-programs'...
   guix system: error: copy-file: No such file or directory: 
"/run/setuid-programs/enoent"
   $ sudoedit /etc/config.scm
   -bash: /run/setuid-programs/sudoedit: No such file or directory
   $ ls -l /run/setuid-programs
   total 0

Expected behavior: the running system is left untouched.
/run/setuid-programs is still populated with the previous generation's
setuid programs. The error message says that the source of the copy-file
doesn't exist, not the destination. (While the latter is technically
correct, it's utterly unhelpful)

3. [OPTIONAL] Run a rollback.

   # guix system roll-back

Expected behavior: /run/setuid-programs gets populated again.
Actual behavior: /run/setuid-programs is still empty.

(Is this a separate bug with roll-back not restoring setuid-programs? No
idea, didn't test)

4. Remove the changes made to the configuration and run reconfigure
   again.

   # guix system reconfigure /etc/config.scm

Expected & actual behavior: system is back in (AFAIK) a well-defined
state.

Regards,
Jakub Kądziołka