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
