[apparmor] [Bug 732837] Re: AF_TIPC not supported by parser when it is in the kernel
apparmor at cboltz.de
Mon Mar 14 22:10:10 UTC 2011
Am Samstag, 12. März 2011 schrieb John Johansen:
> On 03/11/2011 12:39 PM, Steve Beattie wrote:
> > On Fri, Mar 11, 2011 at 10:13:49AM -0800, John Johansen wrote:
> >> On 03/11/2011 04:51 AM, Christian Boltz wrote:
> > We could do a similar build time generation of this list for
> > apparmor.vim. I'm not sure it really improves the situation,
> > however.
> hrmmm, I actually think that isn't a bad idea. We currently have 3
> different sets of names that get auto generated (network families,
> capabilities, rlimits). And we can easily miss new ones being added.
> Christian, what do you think about adding build time generation for
It sounds like a good idea, however the devil is in the details ;-)
- Network families are probably the easiest one because I don't have any
special handling for them. This means they could just be put into
apparmor.vim using sed/$tool.
- Capabilities are already slightly more difficult because I flag some
of them (sys_admin, audit_control etc.) as "dangerous".
Exceptions are the enemy of sed...
- And rlimits are even more interesting because there are various syntax
options depending on which rlimit you set.
You see: more exceptions, and probably nothing to automate...
This means you can't just take apparmor.vim and fill in the capabilities
and rlimit names with sed/$tool.
Beside that, I doubt that the vim maintainer would like to have
in vim.spec ;-) (I hope I'm wrong...)
Oh, and strictly speaking I would also need to introduce a
because the available values could change with the kernel version.
Don't even tell that the vim maintainer...
> I can see doing it two ways, providing a base list that gets replaced
> by auto generation. Or just having the build infrastructure do the
> autogeneration and spit out a warning if it finds the provided list
> and generated lists diverge
Having the list in a file that is generated in the build and included in
the package (apparmor-devel?) would be a good start. However, don't
count too much on a warning - nobody will read it. People only care for
errors that break the build ;-)
Seriously: For openSUSE, I could use a small apparmor-vim-QA package
that compares the text file in apparmor-devel to a given text file and
fails to build if there are changes. The result would be a mail that
tells me about the failure, and I would easily notice the changes.
(It wouldn't be my first *-QA package.)
I'll leave it up to you how to implement the notification for other
This also brings up the more general questions:
- what's the perfect build process (and place for it) for a vim syntax
In theory the best solution would be a separate package, however that
would mean more metadata than content or just to "break a fly on
the wheel" ;-) (the german variant is "shoot sparrows with cannons")
- should I put the files that are used to generate apparmor.vim to some
 RPM metadata is quite small, but I expect the legal team to request
that I include the LICENSE file in the package... (I had that with
patch2mail, which contains 5k useful content and 18k GPL LICENSE.)
Fernsehen und IP sind halt doch zwei verschiedene Dinge, auch wenn
beides oft mit Strom funktioniert. [Peer Heinlein in postfixbuch-users]
More information about the AppArmor