[apparmor] [Bug 732837] Re: AF_TIPC not supported by parser when it is in the kernel

Christian Boltz 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
> apparmor.vim?

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
    BuildRequires: apparmor-devel
in vim.spec ;-)  (I hope I'm wrong...)

Oh, and strictly speaking I would also need to introduce a
    BuildRequires: kernel
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

Good question.

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[1] 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


Christian Boltz

[1] 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 mailing list