[apparmor] [patch] aa-genprof: ask about profiles in extra dir (again)

Christian Boltz apparmor at cboltz.de
Wed Jun 1 12:25:57 UTC 2016


Hello,

Am Dienstag, 31. Mai 2016, 17:22:16 CEST schrieb Seth Arnold:
> On Wed, Jun 01, 2016 at 02:07:10AM +0200, Christian Boltz wrote:
> > thanks to reading the wrong directory in read_inactive_profiles()
> > (profile_dir instead of extra_profile_dir), aa-genprof never asked
> > about using a profile from the extra_profile_dir.
> > 
> > Sounds like an easy fix, right? ;-)
> > 
> > After fixing this (last chunk), several other errors popped up, one
> > after the other:
...
> > I propose this patch for 2.9, 2.10 and trunk
> 
> Acked-by: Seth Arnold <seth.arnold at canonical.com>
> for trunk
> 
> Nice set of fixes; however I'm uncomfortable with making that large a
> change on 2.9, 2.10. I know it's only a wee tiny little code change
> but the semantic idea of the change is quite a bit larger, and it
> doesn't feel appropriate to me to make the change anywhere except
> trunk. (I won't object if someone else ACKs it for 2.9, 2.10.. I just
> don't feel comfortable myself.)

Well, it introduces a behaviour change if a profile exists in extra, 
(asking if the user wants to use this profile as starting point), but
I'd argue that this fixes a regression that was introduced in 2.9 during 
the rewrite to python ;-)

BTW: I tested the patch on top of trunk and the 2.10 and 2.9 bzr branches, 
and it works everywhere.

@John: is your ACK also valid for 2.10 and 2.9?

> I'm also confused by the removal of the CMD_FINISHED; how do you end
> an aa-genprof or aa-logprof session?

CMD_FINISHED is only removed in the question that asks if you want to 
use the profile in extra or if you want to create a new one. And you 
still have Abo(r)t as an option:

# python3 aa-genprof /usr/bin/skype

Profile: /usr/bin/skype

 [1 - Inactive local profile for /usr/bin/skype]                                                                                                                                  
[(V)iew Profile] / (U)se Profile / (C)reate New Profile / Abo(r)t    <--- (F)inish removed here
Writing updated profile for /usr/bin/skype.                                                                                                                                       
Setting /usr/bin/skype to complain mode.                                                                                                                                          

Before you begin, [...]

Profiling: /usr/bin/skype                                                                                                                                                                                                                                                      

[(S)can system log for AppArmor events] / (F)inish                                                                                                                                                                                                                             
[...]

Without my patch, there also was (F)inish at the first question.
However, it behaved exactly like (C)reate New Profile, and continued
with the   (S)can log / (F)inish   question. This means it was a) useless
and b) confusing.

> And, final question:
> > +    profile_data[pname][pname]['filename'] = None  # will be stored
> > in /etc/apparmor.d when saving, so it shouldn't carry the
> > extra_profile_dir filename
> Is this correct? Should it instead be:
> 
> del profile_data[pname][pname]['filename']

Both work. Setting it to None has the advantage that the data structure 
stays complete ('filename' is still there, just empty/None) and can be
used without a .get('filename') safeguard.

> I'm not sure what else may depend upon this being present-but-None vs
> not-even-present. (Half of why I'm excited about the death of the
> hasher..  :)

I'm using a POC "strict storage" patch since a while which changes
profile_storage() to return a dict() with a specified set of sub-items
(so I can notice access to funny[tm] uninitialized places without breaking 
it for users - and actually found some of those places, so I don't want
to merge this patch yet ;-)  I can of course post this patch in case
someone wants to play with it.

The code expects 'filename' to be in the data structure - all checks 
basically use   if ...['filename']:   so setting it to None doesn't 
cause any problems. I'm not aware of any   is None   or   == ''   checks
for it.

TL;DR: I'm quite sure something would explode when using "del" ;-) as
soon as my "strict storage" patch enters the stage.

In theory I could set it to the final filename instead of None - but
write_profile() basically does this itsself (using get_profile_filename())
if 'filename' is empty, so why should I do superfluous work? ;-)

That all said - hasher is not dead yet ;-)


Regards,

Christian Boltz
-- 
<BartOtten> and devs, well they are just a different type of
            human :) [...]
<suseROCKs> Devs are human??  :-)
[from #opensuse-project]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160601/3ade8605/attachment.pgp>


More information about the AppArmor mailing list