[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