Re: [libvirt PATCH] apparmor: Enable passt support

On Tue, Mar 07, 2023 at 01:28:41PM -0800, Andrea Bolognani wrote: > On Tue, Mar 07, 2023 at 07:04:25PM +0000, Daniel P. Berrangé wrote: > > On Tue, Mar 07, 2023 at 08:02:37PM +0100, Andrea Bolognani wrote: > > > + # support for passt network back-end > > > + /usr/bin/passt Cx -> passt, > > > + > > > + profile passt { > > > + /usr/bin/passt r, > > > + > > > + signal (receive) set=("term") peer=/usr/sbin/libvirtd, > > > + signal (receive) set=("term") peer=libvirtd, > > > > What's the rationale for having both qualified & unqualified > > here, but not below ? > > Cargo cult. That's what the top-level profile does, so I figured it > would be good enough for the subprofile too. > > I've seen stuff like peer=(label=libvirtd) as well, but I haven't > investigated the various notations and how exactly they differ. It looks like using the label= version is only needed when additional information is passed, for example in unix (send, receive) type=stream addr=none peer=(label=unconfined addr=none), Each profile has its own name attached as a label, so peer=libvirtd and peer=(label=libvirtd) are effectively equivalent. Similarly, the binary running under a profile also becomes a label, making peer=libvirtd and peer=/usr/sbin/libvirtd also equivalent, which means that having both in the profile is redundant. > There's plenty of room for improvement in the AppArmor profile in > general, but that's a task for another day :) Based on the above, I'm working on a patch that cleans up the situation by sticking with the simpler form. Plus some other stuff. I don't want to make such a cleanup patch a requirement for this functionally relevant one though, especially in the not entirely remote chance that I have completely misunderstood how this stuff work O:-) So I'd prefer to keep the cargo cult line for now, and clean everything up at once later.