2021-03-09 20:40, Rene Engelhard rašė:
I've looked at the
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/03ba395bbe21154efc8a05dfbb9f7c16946eb4d2
diff linked in one of the posts and I see 11 question marks, not 9.
> Hmm, indeed. My bad.
That means we need to do some distinction like you suggested? The
original report just said basically "works if I add another digit", so
that was what I did :-)
Best would be to find source code and see how these random paths are actually generated, instead of guessing. If it's
really 9-to-11, my solution fits.
Complain-by-default is really bad policy, is there a hope to change
that (having it without complain mode, but with "disabled" symlink)?
Personal opinion: I actually consider "ship a profile disabled" even
worse than "complain" since stuff won't even be seen. As of now you see
ALLOWED in the logs at least.
I disagree, as in my case, you can *lose* confinement (security) "silently" after upgrade (when flags=complain returns),
as in this my LibreOffice case. And, for example, Thunderbird package does upgrade it's AppArmor profile, probably
because it's allowed do get new upstream Thunderbird version too, as a exception?
As for visibility, I agree it could be better. For example, maybe `aa-status` could list disabled profiles too. Of
course, profile might be corrupted/buggy/unparsable (and that's why disabled) so care should be taken, but maybe that
would help a bit.
ALLOWED is useful, but maybe we who cares about AppaArmor profiles can just use profiles enforced and report bugs in
Sid, as expected. Well, I did, but got silently "complained"...
