[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


Hello,

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 
distributions.

This also brings up the more general questions:
- what's the perfect build process (and place for it) for a vim syntax 
  file? 
  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
  SVN/whatever?


Regards,

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