On Mon, Jun 26, 2023 at 10:46:40PM +0200, Christian Boltz wrote:
Am Montag, 26. Juni 2023, 18:29:11 CEST schrieb Andrea Bolognani:
> On Mon, Jun 26, 2023 at 09:42:32AM -0600, Jim Fehlig wrote:
> > Specifying which copy to use via a build time option is also an
> > option :-). Does your idea include preserving commit 9b743ee19053
> > and adjusting the 'include if exists' to 'include'?
>
> The modern (3.x) version would install the profile as it is
> currently, while the legacy (2.x) version would have the "include if
> exists" replaced with "include".
Sounds like a good idea.
Okay, looks like we have at least a rough plan. Great!
But this will take some time to implement and test properly, and the
freeze for 9.5 has already started. I recommend reverting 9b743ee for
now, and target 9.6 with the more complete solution.
Jim, does that sound reasonable to you?
These local sniplets are mostly "noise"
(empty/comment-only) files, and
it's harder than needed to find files that were actually modified.
(Besides that, I'm currently testing a set of ~1000 AppArmor profiles,
and having 1000 empty local/ files would make things much harder.)
[...]
If all abstractions would create empty *.d directories by default, that
would be quite some noise and useless directories. So please don't do
that ;-)
I fully agree. As long as the convention is well documented, creating
the additional files and directories is unnecessary at best.
> FWIW, Debian seems to consistently create placeholders for
profiles.
> I think this is done automatically by the dh-apparmor utility that's
> used as standard for packaging. But that feels like a decision better
> left to each downstream... Maybe we should look into what upstream
> AppArmor does for its own profiles and abstractions.
See above - IMHO the current upstream behaviour is not perfect, and will
hopefully change to not creating the local/ files by default in 4.0.
This last bit was more about Debian specifically than upstream, since
IIUC it's dh-apparmor that creates the files. But I see that you're
one of the maintainers for AppArmor in Debian, so I guess you'll be
on top of that on both fronts :)
By the way, is there any plan to move from local/foo to foo.d/ for
profiles too? I imagine that the main concern would be keeping
existing configurations working, but it would be nice to have
consistency between the two, and the foo.d/ approach is generally
much more flexible... 4.0 material, perhaps?
--
Andrea Bolognani / Red Hat / Virtualization