Responses inline
On Sat, Oct 19, 2024, 21:52 Thayne Harbaugh <tha...@mastodonlabs.com> wrote:
> Response in line:
>
> On Sat, 2024-10-19 at 20:36 -0400, Adrian Vovk wrote:
> > Hello,
> > I might have spotted something
>
> Thank you for reviewing my long email.
>
> > You tell repart to encrypt with a keyfile, but it seems like you
> > don't pass in which keyfile to use.
>
> Maybe I'm confused about how Encrypt= and EncryptedVolume= interact.
>
> From repart.d(5) v256.7:
>
> EncryptedVolume=
> Specify how the encrypted partition should be set up. Takes at
> least one and at most three fields separated with a colon
> (":"). The first field specifies the encrypted volume name
> under /dev/mapper/. If not specified, "luks-UUID" will be used
> where "UUID" is the LUKS UUID. The second field specifies the
> keyfile to use following the same format as specified in
> crypttab. The third field specifies a comma-delimited list of
> crypttab options. These fields correspond to the first, third
> and fourth column of the crypttab(5) format.
>
> Note that this setting is only taken into account when
> --generate-crypttab= is specified on the systemd-repart
> command line.
>
> Added in version 256.
>
> My (possibly incorrect) understanding is that EncryptedVolume=
> specifies the key-file in the second position - which in my demo code
> is the following:
>
> Encrypt=key-file
> EncryptedVolume=dc-xdata:/run/fscrypt.sock:luks,discard
>
> Which would then be /run/fscrypt.sock. Am I confused about Encrypt=
> and EncryptedVolume= ?
>
Yeah I think you are. I'm pretty sure EncryptedVolume= is about defining
what goes into /etc/crypttab, and thus how the volume is set up at runtime
or at boot. Not how the volume is set up when it's created. Basically each
EncryptedVolume= entry is an entry in /etc/crypttab and no more.
> > By default, repart will encrypt
> > with a null key in that case. IIRC, you have to pass in the keyfile
> > (or maybe socket) to use in your drop-in.
>
> I feel like I should know what my "drop-in" ... but I have no idea.
> Is thet the repart.d/30-xdata.conf? Is it the override I made to
> systemd-repart.service as
> systemd-repart.service.d/systemd-repart-gen_tabs.conf ?
>
I mean the override you made to systemd-repart.service
Best,
Adrian
> > Apologies if I'm wrong. I'm on my phone and haven't pulled up the
> > docs to verify.
>
> Maybe you can send something with more details when you have access to
> a system.
>
> Thank you for the response.
> > Best,
> > Adrian
> >
> > On Sat, Oct 19, 2024, 20:21 Thayne Harbaugh <tha...@mastodonlabs.com>
> > wrote:
> > > Greetings - apologies if this isn't the proper list - please
> > > redirect
> > > me.
> > >
> > > I'm writing a systemd-repart HOWTO with demo code for various use
> > > cases:
> > >
> > > https://github.com/plastikos/repart_howto
> > >
> > > The HOWTO is a typical document while the demos are minimal cases
> > > built with mkosi and available for growing into larger solutions.
> > >
> > > Initially it has two use-case demos:
> > >
> > > 1. Creating a new partition (xdata) on first boot
> > >
> > > 2. Creating a new partition (xdata) with encryption on first boot
> > >
> > > Currently #1 works. It's simple. I still need to create more
> > > details
> > > around growing partitions and other ideas.
> > >
> > > The encryption case #2, however, does not work and I'm looking for
> > > some assistance. While there is significant documentation around
> > > the
> > > systemd ecosystem of tools I feel like I have possibly missed some
> > > detail or may not be understanding how to synthesize the
> > > information
> > > into a working model.
> > >
> > > The encryption demo is identical to case #1 of adding a partition
> > > with
> > > the following changes:
> > >
> > > 1. The /usr/lib/repart.d/30-xdata.conf file adds the following:
> > >
> > > Encrypt=key-file
> > > EncryptedVolume=dc-xdata:/run/fscrypt.sock:luks,discard
> > >
> > > 2. a /usr/lib/systemd/system/fscrypt.socket file is added along
> > > with
> > > a fscrypt@.service file (see the project source, please).
> > >
> > > 3. A /usr/bin/getkey file is added for fscrypt@.service to call.
> > > getkey provides a simplistic way of producing an encryption
> > > key
> > > for *demonstration* purposes *ONLY*.
> > >
> > > 4. A /var/lib/key.bin is added as a binary encryption key that
> > > getkey retrieves - for *demonstration* purposes *ONLY*.
> > >
> > > When built into a disk image by mkosi and started with qemu it
> > > fails
> > > to create the new xdata partition. I see quite a few journal
> > > messages
> > > from systemd-repart and related udev events. I have verified a few
> > > things:
> > >
> > > 1. /run/fscrypt.sock does get created
> > >
> > > 2. getkey does emit the encryption key to stdout
> > >
> > > 3. systemd-repart is started and initiates creating a partition
> > > with
> > > LUKS
> > >
> > > There are two notable details that cause me concern and might be
> > > where
> > > the problem lies:
> > >
> > > 1. There is no evidence that getkey is invoked even when I
> > > instrument it to generate side-effects.
> > >
> > > 2. There are messages in the journal that indicate that
> > > systemd-repart never exits and that it might be in deadlock
> > > waiting
> > > for child events.
> > >
> > > The messages around the possible deadlock of #2 above are the
> > > following:
> > >
> > > Oct 19 12:08:48.510843 localhost systemd-repart[276]: loop0:
> > > Acquired exclusive lock.
> > > Oct 19 12:08:48.512130 localhost systemd-repart[276]:
> > > Successfully acquired /dev/loop0, devno=7:0, nr=0, diskseq=11
> > > Oct 19 12:08:48.516941 localhost systemd-repart[276]: Encrypting
> > > future partition 2...
> > > Oct 19 12:08:48.517077 localhost systemd-repart[276]: Allocating
> > > context for crypt device /dev/loop0.
> > > <SNIP/>
> > > Oct 19 12:08:49.114118 localhost (udev-worker)[299]: loop0:
> > > Processing device (SEQNUM=1996, ACTION=change)
> > > Oct 19 12:08:49.114972 localhost (udev-worker)[299]: loop0:
> > > Failed to flock(/dev/loop0): Resource temporarily unavailable
> > > Oct 19 12:08:49.114979 localhost (udev-worker)[299]: loop0: Block
> > > device is currently locked, requeueing the event.
> > > <SNIP/>
> > > Oct 19 12:08:49.328308 localhost (udev-worker)[296]: loop0:
> > > Processing device (SEQNUM=1996, ACTION=change)
> > > Oct 19 12:08:49.328345 localhost (udev-worker)[296]: loop0:
> > > Failed to flock(/dev/loop0): Resource temporarily unavailable
> > > Oct 19 12:08:49.328352 localhost (udev-worker)[296]: loop0: Block
> > > device is currently locked, requeueing the event.
> > > <SNIP/>
> > >
> > > Those last three messages about failing to lock repeat until QEMU
> > > is
> > > shut down.
> > >
> > > There are quite a few additional diagnostic details and logs that
> > > may
> > > be of interest but it might be easier to clone the repart_howto
> > > project from github and run it:
> > >
> > > >$ ./demo crypt
> > >
> > > Once it executes all of the mkosi configuration files and disk
> > > image
> > > are in the build-crypt sub-directory. All relevant files specific
> > > to
> > > partition creation and encryption are in build-crypt/mkosi.extra -
> > > there are not many since I'm trying to keep the demo as simple as
> > > possible. All relevant journal events and state information can be
> > > extracted from build-crypt/image.raw.
> > >
> > > Thanks for either directing me to a more appropriate help resource
> > > and/or providing direct assistance.
> > >
> > >
> > > P.S. If you want to run demo #1 of partition creation sans
> > > encryption
> > > then execute the following from the project source tree:
> > >
> > > >$ ./demo clear
>
> --
> Big Solutions
>
