On Mon, Sep 16, 2024 at 04:13:03PM GMT, Daniel P. Berrangé wrote:
On Tue, Sep 17, 2024 at 12:12:05AM +0900, Andrea Bolognani wrote:
> On Mon, Sep 16, 2024 at 04:04:40PM GMT, Daniel P. Berrangé wrote:
> > On Mon, Sep 16, 2024 at 04:55:55PM +0200, Andrea Bolognani wrote:
> > > static virSecurityDriverStatus
> > > AppArmorSecurityManagerProbe(const char *virtDriver G_GNUC_UNUSED)
> >
> > We're passing the virt driver name ("QEMU" or "LXC") in
here and not using
> > it.....
> >
> > ...rather than delete these, pick the right check to perform based
> > on 'virtDriver' value.
> >
> > eg approximately like this
> >
> > g_autofree char *template_name = g_strdup(virtDriver);
> > for (i = 0; template_name[i]; i++)
> > template_name[i] = tolower(template_name[i])
> > template = g_strdup_printf("%s/TEMPLATE.%s", APPARMOR_DIR
"/libvirt", template_name)
>
> I can give it a shot, but it still seems pointless to check whether
> the files are available ahead of time when virt-aa-helper will do
> that at the time when they're actually going to be used. What do we
> gain by doing that?
Do we still get a clear error message back to the user if virt-aa-helper
fails due to the missing files ?
Clear-ish.
This is what the failure will look like to the user:
$ virsh start cirros
error: Failed to start domain 'cirros'
error: internal error: cannot load AppArmor profile
'libvirt-70a00233-4e17-4038-9e03-f84d35ba28e9'
The journal will contain additional information:
internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr
/usr/lib/libvirt/virt-aa-helper -c -u
libvirt-70a00233-4e17-4038-9e03-f84d35ba28e9)
unexpected exit status 1: virt-aa-helper: error:
template does not exist
virt-aa-helper: error: could not create profile
internal error: cannot load AppArmor profile
'libvirt-70a00233-4e17-4038-9e03-f84d35ba28e9'
Note that, even before this change, the actual issue was only
reported in the journal as:
internal error: template '/etc/apparmor.d/libvirt/TEMPLATE.qemu'
does not exist
I could perhaps enhance the error reported by virt-aa-helper so that
the path of the missing template is included, but let's keep in mind
that this failure will only be reported if the deployment is severely
borked (i.e. the package containing the driver is installed but some
of its files are missing for whatever reason) so I think it's
appropriate to have the details reported in the journal only. The
admin is the only one who can act upon them anyway.
--
Andrea Bolognani / Red Hat / Virtualization