[apparmor] GSoC week 1

[Kshitij Gupta]

Hello,

On Mon, Jun 17, 2013 at 4:30 AM, Christian Boltz <apparmor at cboltz.de> wrote:
> Hello,
>
> some short feedback on
> http://kshitijblogs.blogspot.in/2013/06/week-0-coding-period-begins.html
>
>> 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
> improvements.
>
> In theory that means that you'll need to do the following changes in
> commentparser.py:
> - 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
though.

> 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
> modules.)
> 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. ;-)

Regards,

Kshitij Gupta