On Thu, Jan 30, 2020 at 8:06 AM Michal Privoznik <mprivozn@xxxxxxxxxx> wrote:
The location of virt-aa-helper shown in the docs is incorrect.
The helper binary is installed under libexec dir.
Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
---
docs/drvqemu.html.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/drvqemu.html.in b/docs/drvqemu.html.in
index 87542afd27..93a7e6e7df 100644
--- a/docs/drvqemu.html.in
+++ b/docs/drvqemu.html.in
@@ -439,7 +439,7 @@ chmod o+x /path/to/directory
<p>
While users can define their own AppArmor profile scheme, a typical
configuration will include a profile for <code>/usr/sbin/libvirtd</code>,
- <code>/usr/lib/libvirt/virt-aa-helper</code> (a helper program which the
+ <code>/usr/libexec/virt-aa-helper</code> (a helper program which the
Don't get me wrong please the changes in this series seem correct to me to have filenames/doc match the rest of the code.
But as it became clear in the discussion on v1 - the two Distributions that actually run apparmor usually (Suse and Ubuntu) have the helper in different places.
We seem to agree on the rules to list a multitude of paths.
But I wonder if in docs and makefiles this should be part of the .html.in -> .html conversion to set the right paths for each.
Otherwise Suse and Ubuntu will have to carry reverts or modifications of these changes forever.
For example the path above is in fact the correct path on Ubuntu - that might also be the history how it became that way in the src.
Essentially this comes through config option --libexecdir=/usr/lib/libvirt, so we would not even have to add a new argument for this.
What do others think about this (for all the patches of the series it applies to)?
libvirtd daemon uses instead of manipulating AppArmor directly), and
an abstraction to be included by <code>/etc/apparmor.d/libvirt/TEMPLATE</code>
(typically <code>/etc/apparmor.d/abstractions/libvirt-qemu</code>).
--
2.24.1
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
Staff Engineer, Ubuntu Server
Canonical Ltd
