Hello,
The nova-hypervisor snap for OpenStack uses a number of privileged interfaces:
system-trace, hardware-observe, system-observe, process-control, openvswitch, libvirt, network-observe, network-control, firewall-control
The source for this snap is located at: https://github.com/openstack/snap-nova-hypervisor
Can these interfaces be auto-connected?
Thanks,
Corey
This is a lot of privilege being given to nova, but I know nova needs most of them. Can you comment on why nova needs system-trace? This is the only one I was surprised about.
Hi jdstrand, sorry just verifying this and ran across some other issues that I need to handle to verify completely. It looks like we don’t need system-trace. I think this was added for ovs tracing but I’m not sure it’s necessary. I’ll get back to you soon for sure though.
@jdstrand, apologies for the delayed reply. I ran across a few more issues in testing system-trace and wanted to make sure we have everything covered in this request.
It turns out we do not need system-trace. I think it may have been added for openvswitch tracing but it’s not required for mainline execution, so let’s not add it for now.
We do, however, need to add account-control and kernel-module-control plugs to the list of auto-connected interfaces, in addition to those listed in the original request above.
Thanks,
Corey
Why is account-control needed? I’d not expect nova to be managing accounts in the machine. And similar question for kernel-module-control. Those two interfaces means the snap can do pretty much anything at all.
That’s not a reasonable use of the interface, so -1 on auto-connecting it.
Happy to discuss alternatives.
Fair enough, it does seem a bit forced.
@niemeyer, I think we can drop kernel-module-control as well. While we get the denial below (looks like iproute2 is calling into iptables which does some modprobing), my basic mainline testing seems to be ok without that interface so lets not include kernel-module-control for now.
= AppArmor =
Time: Jul 3 18:02:33
Log: apparmor=“DENIED” operation=“capable” profile=“snap.nova-hypervisor.nova-compute” pid=18201 comm=“ip” capability=16 capname=“sys_module”
Capability: sys_module
Suggestions:
Just to be clear, at this point the interfaces we’re requesting auto-connection for are:
hardware-observe, system-observe, process-control, openvswitch, libvirt, network-observe, network-control, and firewall-control
Wrt kernel-module-control, most applications do not need to be able load arbitrary modules on the system, which is what kernel-module-control gives. Instead, they want specific modules loaded and are very happy if the module is already loaded into the kernel. As a result, the is a ‘kmod’ backend in the interfaces code that can be used to tell snapd to load modules that are needed by the interface on behalf of the application. Eg, we load several firewall modules when something plugs firewall-control.
What module is ip trying to load? If you actually need the module, perhaps it can simply be added to an existing interface or a new interface?
@coreycb - wrt accounts-control, I agree with @niemeyer.
chmod? This is already included in the default template. Did you mean chown? If so, what is it trying to chown?
In my experience, nova needs all of these. +1
Yes I think it was chown. I’ve since patched the upstream code as it’s not needed while running as root.
Ok, note this topic which you might want to keep an eye on: Snappy and users and groups (obsolete)
AIUI, the recent sprint had some discussions surrounding this.
@jdstrand Thanks for the info on the kmod backend. Very good to know in case we end up needing to load a module.
+1 to this list as well.
Request to auto-connect hardware-observe, system-observe, process-control, openvswitch, libvirt, network-observe, network-control, and firewall-control:
2 votes for
0 against
0 abstained
Request granted in the store and it is live.
