While the python-based AppArmor utils (aa-logprof etc.) are much easier to understand and maintain than the old perl code, there are still some terribly long functions like parseprofiledata() in aa.py that are not too easy to understand. Also, using hasher() (a recursive array) as storage can have some strange side effects. Another problem is that test coverage isn't too good, especially for the bigger functions.

I already wrote the CapabilityRule and CapabilityRuleset classes (and also the BaseRule and BaseRuleset classes) some months ago, and changed the code to use those classes. This code is already in upstream bzr.

My plan for hackweek is to convert more rule types into classes, and to add full test coverage for them. Besides much more readable code, this will also result in "accidently" fixing some bugs that were not noticed yet.

A side goal is to keep the upstream devs busy with patch reviews by continueing my patch flood I started some weeks ago *g*

I'll start with network rules / the NetworkRule and NetworkRuleset classes, and then maybe roll a dice to decide what I'll convert next ;-)

Looking for hackers with the skills:

apparmor python tests

This project is part of:

Hack Week 12

Activity

  • over 10 years ago: cboltz added keyword "apparmor" to this project.
  • over 10 years ago: cboltz added keyword "python" to this project.
  • over 10 years ago: cboltz added keyword "tests" to this project.
  • over 10 years ago: cboltz liked this project.
  • over 10 years ago: cboltz started this project.
  • over 10 years ago: cboltz originated this project.

  • Comments

    • cboltz
      over 10 years ago by cboltz | Reply

      Some minutes ago, I finally commited the NetworkRule and NetworkRuleset classes (and the patch that actually uses them) to AppArmor bzr - they were delayed by some previous patches with a slower-than-usual review (dependencies not only happen for packages ;-)

      I'll continue to rewrite more rule types into classes, but that will probably have to wait after oSC15 and can also happen without formal hackweek tracking ;-)

    Similar Projects

    Bring to Cockpit + System Roles capabilities from YAST by miguelpc

    Bring to Cockpit + System Roles features from YAST

    Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.

    Goals

    The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.

    Resources

    A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit

    Linux System Roles: https://linux-system-roles.github.io/