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