[apparmor] GSoC week 1
kgupta8592 at gmail.com
Mon Jun 17 17:56:52 UTC 2013
On Mon, Jun 17, 2013 at 4:30 AM, Christian Boltz <apparmor at cboltz.de> wrote:
> some short feedback on
>> Work on config module, which is basically a tool to read and write the
>> config files. We have had certain ideas to use configparser and shlex
>> modules in it, but they tend to loose the comments so a solution needs
>> to be arrived at.
> I still tend to use configparser and shlex - it's better (and hopefully
> faster) to improve them than to write something from scratch. A positive
> side effect will be that other users of those modules will also get the
> In theory that means that you'll need to do the following changes in
> - in read(), store the comments somewhere[tm] instead of just stripping
> them (note that it handles inline comments and full line comments in
> different code blocks)
> If I had to write it, I'd make the "somewhere" inside self._sections
> to store the comments and their location like
> - "at the beginning of the file"
> - "before "[foo]"
> - "before [foo] bar="
> - "at [foo]" (inline comment)
> - "at [foo] bar=" (inline comment)
> - "at the end of the file"
> Typically full line comments are above the line they describe, and
> inline comments are (obviously) right of the setting they describe, so
> that should be the way how you store the comment location.
> - in write() and _write_section(), write the comments back at their
> original location (that's why you stored the location ;-)
> If the setting a comment was related to was removed, write it at the
> the end of the section.
> The changes to shlex should be even easier because shell-style config
> files are "flat" and don't have sections.
> That said, if this turns out to be more difficult than I'm thinking ;-)
> I'll of course also accept a new module - but I'm quite sure that
> writing your own module will be more difficult than fixing the comment
> handling in the existing modules.
Thanks Christian for the review. I had a similar idea about storing
the comments, albeit you were more elaborate and detailed than my
vague vision. :-)
I think its something I'll run along with and get back to you with
some working code very soon. ATM I'm working on a different module
> BTW: You'll need similar comment handling when reading, updating and
> writing profiles ;-)
>> Work on the severity module which helps resolve the severity of
>> various accesses by the programs.
> Yes, that's also a good starting point.
>> Work on repository module.
> The online profile repo is probably not the most urgent stuff ;-)
I'll mark that off my list for now. I think I'll get a tree diagram or
something to keep a track of all the modules.
>> Besides these, we also need to discuss whether notify module needs to
>> be done now or pushed until later, since it needs YCP.
> The notification/report stuff that was part of YaST is unmaintained
> since quite some time. Its replacement, aa-notify, does something
> similar (but not exactly the same) - but not integrated in YaST.
> Besides that, the YaST team is moving away from YCP as programming
> language. (YCP is a language specific to YaST, and not many people
> understand it, which also means it's hard to find maintainers for YaST
> They have a tool to (mostly) automatically convert YCP to ruby, but
> there are also YaST python bindings which might be a better choice in
> our case because we want to use the python libraries you'll write.
> Anyway, I'd say we need a working base (python modules + commandline
> interface) first. When we have that, we can add the YaST user interface
> on top.
That's off too. ;-)
More information about the AppArmor