On Wed, Mar 08, 2023 at 09:23:19AM -0800, Andrea Bolognani wrote:
> 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.
Sure, if its already inconsistent, then this makes it no worse...
Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
