[apparmor] deglobal-profiledir.diff (was Re: [patch] try to make subdomain.pm a little less smelly.)
Steve Beattie
steve at nxnw.org
Thu Oct 7 00:01:13 BST 2010
On Tue, Oct 05, 2010 at 11:51:56PM -0700, Jesse Michael wrote:
> deglobal-profiledir.diff
> - get rid of global $profiledir variable and explictly pass it into
> functions that use it
Hrm, after applying this patch, it seems that delete_profile()'s
prototype has changed but has no callers. Unfortunately, openSUSE is
carrying the following patch, which does invoke delete_profile():
From: Jeff Mahoney <jeffm at suse.com>
Subject: [PATCH] apparmor-utils: cleanup after abort in genprof
References: bnc#307067
The initial generation of the base profile is required to be written out
to put the process in complain mode for observation. If the user
decides to abort the profiling session, that base profile is left
behind.
This patch removes all profiles created during the run up to an abort.
Signed-off-by: Jeff Mahoney <jeffm at suse.com>
---
SubDomain.pm | 3 +++
1 file changed, 3 insertions(+)
--- a/utils/SubDomain.pm
+++ b/utils/SubDomain.pm
@@ -1747,6 +1747,9 @@ sub confirm_and_abort {
if ($ans eq "y") {
UI_Info(gettext("Abandoning all changes."));
shutdown_yast();
+ foreach my $prof (@created) {
+ delete_profile($prof);
+ }
exit 0;
}
}
which I was about to propose for us to incorporate. However, unwinding
the call chains to include $profiledir (and $sd) starts to get pretty
complex, as it hits most of the UI layer. I can generate it the patch
but it starts to return both variables to their global status if they
just get passed around everywhere, perhaps pointing out a weakness of
this approach. Is there any way we can encapsulate these in a way that
they don't need to be passed all over the place?
--
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/apparmor/attachments/20101006/36bd8950/attachment.pgp
More information about the AppArmor
mailing list