Package: fai-setup-storage
Version: 6.2.3
Severity: important

I have used setup-storage as part of a bespoke installer we've built
here over the years, made of setup-storage and grml-debootstrap,
essentially. The source code is kind of embarrassing, but it's here if
you want to see the gory details:

https://gitlab.torproject.org/tpo/tpa/fabric-tasks/-/blob/ca6d9584c2a57fa8933fc2b499394c550326aa1f/fabric_tpa/install.py

This was working well: setup-storage was doing the hard work of
partitioning and mounting the disks, and grml-debootstrap was doing
the rest.

(I know we should probably just be using FAI, but i've been having
trouble setting it up in our heterogenous environment.)

One of the things our setup does is use the LUKS keyfiles generated by setup-storage to add a new, password-based, encryption key that gets
added to the key slots. This was working because a keyfile was
leftover in /tmp/fai, and indeed the setup-storage manual page
indicates that's expected behavior.

Except something happened recently that made that file disappear. I
have verified this during an install, where the file was removed at
some point. I can't exclude the possibility that something in grml or
our script wipes away that keyfile, but I don't understand why it
would wipe *just* that keyfile. And indeed, if I copy the file out
*while* setup-storage is running, i can restore it after it exits, and
our installer works again.

So it looks like setup-storage's behavior changed there, and it
deletes keyfiles on exit.

Is that intentional? Is that a correct assessment?

Could we revert this? I understand having plain text keyfiles in /tmp
is probably not the best idea, security wise, but it's something we
currently depend on. Writing a secret in the setup-storage
configuration file is not an option.

Thanks!


-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.17-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fai-setup-storage depends on:
ii e2fsprogs 1.47.2-1
pn liblinux-lvm-perl <none>
ii libparse-recdescent-perl 1.967015+dfsg-4
ii parted 3.6-5
ii perl 5.40.1-2

Versions of packages fai-setup-storage recommends:
pn fai-client <none>
ii lvm2 2.03.27-1
ii mdadm 4.4-5

Versions of packages fai-setup-storage suggests:
ii cryptsetup 2:2.7.5-1
ii dmsetup 2:1.02.201-1
ii dosfstools 4.2-1.1
pn jfsutils <none>
ii ntfs-3g 1:2022.10.3-5
ii reiserfsprogs 1:3.6.27-9
ii xfsprogs 6.13.0-2

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-03-12 08:03:04, Thomas Lange wrote:

This change was added in FAI 6.0 (see commit below), but since FAI 6.2 there's a variable called FAI_KEEP_CRYPTKEYFILE. This is now the code snippet:

# clean crypt key files
unless (defined ($ENV{'FAI_KEEP_CRYPTKEYFILE'})) {
foreach (@FAI::crypttab) {
my $fname = (split)[0];
unlink "$FAI::DATADIR/$fname";
}
}

Ha! Thanks for the confirmation, that's such a relief: I thought
something was really wrong with the universe.

Perhaps that should be documented in the manual page? That would be
enough, in my view, to close this bug report. :)

Could you clarify what the intention is behind this change? If the
keyfile is deleted, there's no way for anything to unlock the device
after setup-storage has ran, no? In that case, how does one make use of
the partition?

Or is there a way to add a keyslot to an opened LUKS device that we
don't have a passphrase or keyfile for that I don't know about?

Thanks again!

--
Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
- Aristote

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)