On Mon, Mar 30, 2026 at 12:24:06PM +0530, Arun Menon wrote:
> Hi Andrea,
>
> Thank you for finding this.
>
> On Sun, Mar 29, 2026 at 03:12:25PM -0500, Andrea Bolognani wrote:
> > On Tue, Feb 10, 2026 at 11:26:39PM +0530, Arun Menon via Devel wrote:
> > > This commit sets the foundation for encrypting the libvirt secrets by
> > > providing a
> > > secure way to pass a secret encryption key to the virtsecretd service.
> > >
> > > A random secret key is generated using the new virt-secret-init-encryption
> > > service. This key can be consumed by the virtsecretd service.
> > >
> > > By using the "Before=" directive in the new virt-secret-init-encryption
> > > service and using "Requires=" directive in the virtsecretd service,
> > > we make sure that the daemon is run only after we have an encrypted
> > > secret key file generated and placed in /var/lib/libvirt/secrets.
> > > The virtsecretd service can then read the key from CREDENTIALS_DIRECTORY.
> > > [1]
> >
> > [...]
> >
> > > +++ b/src/remote/libvirtd.service.in
> > > @@ -12,6 +12,8 @@ After=libvirtd.socket
> > > After=libvirtd-ro.socket
> > > After=libvirtd-admin.socket
> > > Requires=virtlogd.socket
> > > +Requires=virt-secret-init-encryption.service
> > > +After=virt-secret-init-encryption.service
> > > Wants=virtlockd.socket
> > > After=virtlogd.socket
> > > After=virtlockd.socket
> > > @@ -29,6 +31,8 @@ Conflicts=xendomains.service
> > > Type=notify-reload
> > > Environment=LIBVIRTD_ARGS="--timeout 120"
> > > EnvironmentFile=-@initconfdir@/libvirtd
> > > +Environment=SECRETS_ENCRYPTION_KEY=%d/secrets-encryption-key
> > > +LoadCredentialEncrypted=secrets-encryption-key:@localstatedir@/lib/libvirt/secrets/secrets-encryption-key
> >
> > A bit late to the party, sorry.
> >
> > This change breaks the scenario in which the monolithic daemon is in
> > use and the secret driver is not installed. The error messages is
> > quite clear about what's wrong:
> >
> > $ sudo systemctl start libvirtd.service
> > Failed to start libvirtd.service: Unit
> > virt-secret-init-encryption.service not found.
> >
> > I thought I could fix things by weakening the Requires= into a Want=,
> > which would feel appropriate for an optional component, however that
> > doesn't work either:
> >
> > systemd[1]: Starting libvirtd.service - libvirt legacy monolithic
> > daemon...
> > (libvirtd)[20437]: libvirtd.service: Failed to set up credentials:
> > No such file or directory
> > (libvirtd)[20437]: libvirtd.service: Failed at step CREDENTIALS
> > spawning /usr/sbin/libvirtd: No such file or directory
> > systemd[1]: libvirtd.service: Main process exited, code=exited,
> > status=243/CREDENTIALS
> > systemd[1]: libvirtd.service: Failed with result 'exit-code'.
> >
> > Based on my reading of systemd.exec(5), there doesn't seem to be a
> > way to make this conditional. ImportCredential= is supposed to behave
> > gracefully when the credential doesn't exist, but I don't think it
> > suits our needs otherwise.
>
> We can change the Requires= to Wants=, like you mentioned, it will
> gracefully skip if the encryption service is not found.
Yeah, this part is easy.
> Can we move the LoadCredentialEncrypted= and Environment= out of
> libvirtd.service.in in to a separate file, and then use meson.build to
> optionally install the new file to the configuration directory
> systemd/system/libvirtd.service.d/ if conf.has('WITH_SECRETS') is set?
That won't work, because when building distro packages all features
get enabled at compile time. The decision about whether the
rpm/deb/whatever containing the secret driver gets installed is made
later, by the local admin, and is completely out of our control.
--
Andrea Bolognani / Red Hat / Virtualization
