Hi Mark,
> fixed in the Leafnode package.  Now you're telling me that this should,
> as I had originally understood, be fixed in the SELinux packages.

It requires knowledge of leafnode to be fixed. Ideally, it would be
fixed within the leafnode package, albeit it's more realistically and
practicably to do it in the refpolicy package (at least when you submit
the module upstream and they include it - we don't really want to have
two different versions of the policy module unless there is a good
reason to do so!)

> I'm sorry, I can't entirely parse what you're saying here.  You appear
> to be talking about having the ability to build new SELinux policies?

No, I'm talking about the toolchain to build SELinux policy MODULES.
Which is what you need for leafnode.

> This is obviously true - the point is that there is no visible support
> for including new SELinux policy information in packages.

Incorrect. Just ship a .pp (= policy package, aka policy module) file.
The -dev package I mentioned is what you need for building the .pp file.

Let me quote the description of the -dev package:
[...]
 This package provides header files for building your own SELinux
 policy packages compatible with official policy packages.

See, you probably want to make an 'unofficial' policy package for
leafnode, then try to get it 'official'.

> Either you want me to implement SELinux support in the Leafnode package
> or you want this to be done in the SELinux packages.  Which is the case?

*I* do not care. Heck, I don't even care if leafnode ever gets a policy
module, since I don't use it. Nor do I currently use SELinux, but that's
another story. The -dev package exists to allow you building a policy
module for leafnode.
As explained, writing a module for leafnode requires knowledge of where
leafnode stores it's files and which kind of access it needs to these
files and other system files.
For maintainance reasons (keeping up with SELinux changes such as
labeled networking), it's most convenient if you submit the policy
module to refpolicy upstream, but of course you can also just keep it in
your package. Someone wrote a policy module for exim and submitted it
upstream, now it's included there. Sounds like a working approach to me.
Go ahead and clone the bug to the refpolicy package, but at least use
the correct package, please. But don't expect that to help getting the
bug resolved; the usertag already added is more appropriate for tracking
SELinux related issues.

best regards,
Erich Schubert
-- 
     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
 Nothing prevents happiness like the memory of happiness. --- A. Gide //\
        Es gibt kein idiotensicheres Programm, weil Idioten so        V_/_
                       genial sind. -- E. Murphy




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to