On Monday 21 May 2007 22:56, Erich Schubert [EMAIL PROTECTED] wrote:
How would that method cope with a cross-build? Emdebian has already
built some selinux packages from the Debian sources for a rootfs and
We're talking about policy package dependencies, not about debian
package
On Wednesday 09 May 2007 10:34, Erich Schubert [EMAIL PROTECTED] wrote:
SELinux policy modules and debian packages, which discovers the
relationships between modules and orders the policy load correctly, so
that it can pull in any dependency as required.
Yep, I'm generating them on
On Mon, 21 May 2007 19:08:34 +1000
Russell Coker [EMAIL PROTECTED] wrote:
On Wednesday 09 May 2007 10:34, Erich Schubert [EMAIL PROTECTED] wrote:
SELinux policy modules and debian packages, which discovers the
relationships between modules and orders the policy load correctly, so
Hello Neil,
Yep, I'm generating them on compile time in my packages and storing them
in an auxillary file. shipping another 1k file with the package felt
nicer to me than computing it on install time.
That's fine as long as the dependencies don't change due to local
modifications.
On Mon, 21 May 2007 14:56:49 +0200
Erich Schubert [EMAIL PROTECTED] wrote:
Hello Neil,
Yep, I'm generating them on compile time in my packages and storing them
in an auxillary file. shipping another 1k file with the package felt
nicer to me than computing it on install time.
On Wed, May 09, 2007 at 02:34:18AM +0200, Erich Schubert wrote:
I don't think this is a good idea. If I have (for whatever reason) to
modify a policy module, I'd like to be able to bump the version number a
bit to avoid it from being updated. Like bumping it to 2.x; it will be
some time until
Hi,
OK. Given a .pp file, how _do_ you detect what version it is?
For installed modules, we can just use semodule -l
I havn't tried it, but there is
semanage.semanage_module_get_version
in the python semanage bindings.
I don't know if this only works for installed modules or for
On Wed, 9 May 2007 13:00:14 +0200, Gabor Gombas [EMAIL PROTECTED] said:
Well, I don't know much about SElinux (yet) but how about storing the
modified module at a different location (say under
/var/selinux/local-policy)? That way the update script can be taught
to simply ignore the shipped
Hi,
There was a problem with how our refpolicy packages were put
together -- modules that were included in base where still built and
shipped in /usr/share/selinux/$policy_name/*.pp; but they could not be
installed, since there was a conflict -- they had already been
installed by
Hello Manoj,
I think we need to create a tool that can update your policy
setup, taking into account any new packages you might have installed in
the meanwhile and loading new modules as needed. This is the first
Like the update-selinux-policy command in my packages does?
On Wed, 09 May 2007 00:09:12 +0200, Erich Schubert [EMAIL PROTECTED] said:
Hello Manoj,
I think we need to create a tool that can update your policy setup,
taking into account any new packages you might have installed in the
meanwhile and loading new modules as needed. This is the first
Hello Manoj,
Hmm. Python. I think I looked at that when I implemented the
Well, that script actually is shell.
The python script is what I use to do the autodetection magic.
SELinux policy modules and debian packages, which discovers the
relationships between modules and orders the
On Wed, 09 May 2007 02:34:18 +0200, Erich Schubert [EMAIL PROTECTED] said:
Hello Manoj,
Hmm. Python. I think I looked at that when I implemented the
Well, that script actually is shell.
Err, I can read. The guts of the magic was, as you say, in python.
The python script is what I
13 matches
Mail list logo
