[apparmor] RFC: The future of "(V)iew Changes" in aa-logprof
Christian Boltz
apparmor at cboltz.de
Sun Jun 3 13:58:47 UTC 2018
Hello,
at the openSUSE Conference, I talked with John about how aa-logprof
writes profiles for the diff view, just came up with a possible solution
I didn't consider before, and would now like to hear some feedback ;-)
As you know, aa-logprof has two options to display a profile diff:
- (V)iew Changes
- View Changes b/w (C)lean profiles
The first option uses some quite old code [1] (including a few known
bugs) to write the updated profile, and then shows the diff to the
profile in /etc/apparmor.d/. It has the intention to keep the diff
readable, but this doesn't always work.
The second option writes both the old and new profile in "clean" mode
[2] and then diffs them - which in practise makes the diff much shorter,
but also hides the cleanup changes that will happen to the profile when
writing it.
When actually writing the profile, it always gets written in clean mode.
This means both diff variants do not really represent what will happen
to the file in /etc/apparmor.d:
- (V)iew Changes uses write code that differs from how the profile
really gets written (diff view uses [1], but writing the profile
happens in clean mode [2])
- View Changes b/w (C)lean profiles uses the correct write code [2], but
does the diff to a "clean" old profile instead of the real old profile
in /etc/apparmor.d/. This keeps the diff very readable, but also means
the cleanup that will be done to the profile doesn't get displayed in
the diff.
Now the question is - what behaviour do we want in the future?
My prefered option would be to change (V)iew Changes so that it writes
the new profile in clean mode instead of least-possible-changes mode.
Advantages would be:
- it gives users the "real" diff that will be applied when writing the
profile
- it would be the easiest way - basically I could drop the code to
write the profile with minimum changes [1], and would have at least
400 lines less to maintain [3]
- it would make future changes to aa-logprof (like support for nested
child profiles) easier because we'd have only one way to write
profiles
An alternative would be to completely rewrite the (V)iew Changes code so
that it writes a profile with minimum changes - and then introduce an
option to really write the profile in that mode.
Needless to say that this is quite some work, and I seriously doubt if
it's worth the effort.
Since this mail is quite long, let me sum it up in pseudocode:
(V)iew Changes (current implementation):
- write_new_profile_with_minimum_changes to tempfile
- diff /etc/apparmor.d/$profile $new_profile_with_minimum_changes
- write new_profile_clean to /etc/apparmor.d
Proposed behaviour for (V)iew Changes:
- write_new_profile_clean to tempfile
- diff /etc/apparmor.d/$profile $new_profile_clean
- write new_profile_clean to /etc/apparmor.d
View Changes b/w (C)lean profiles:
- write_new_profile_clean to tempfile
- write_old_profile_clean to tempfile
- diff $old_profile_clean $new_profile_clean
- write new_profile_clean to /etc/apparmor.d
Opinions?
Regards,
Christian Boltz
[1] serialize_profile_from_old_profile() in aa.py
[2] serialize_profile() in aa.py
[3] serialize_profile_from_old_profile() has about 400 lines, so this
number doesn't even include helper functions that might become
superfluous
--
Well, I guess, Stephan knows very well, what the fuzz is about: it's
about hundreds of patches, which will have to be regenerated, done as
an employment-creation measure for this lazy gang of packagers.
[Hans-Peter Jansen in opensuse-packaging]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180603/68b11600/attachment.sig>
More information about the AppArmor
mailing list