All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl MacMillan <kmacmillan@mentalrootkit.com>
To: Joshua Brindle <jbrindle@tresys.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	Daniel J Walsh <dwalsh@redhat.com>,
	SE Linux <selinux@tycho.nsa.gov>
Subject: RE: I would like to propose that we add compression to handle allpolicy files on disk.
Date: Thu, 09 Nov 2006 13:43:50 -0500	[thread overview]
Message-ID: <1163097830.32083.52.camel@localhost.localdomain> (raw)
In-Reply-To: <6FE441CD9F0C0C479F2D88F959B01588514F17@exchange.columbia.tresys.com>

On Thu, 2006-11-09 at 12:00 -0500, Joshua Brindle wrote:
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > 
> > On Thu, 2006-11-09 at 10:13 -0500, Stephen Smalley wrote:
> > > On Thu, 2006-11-09 at 09:34 -0500, Joshua Brindle wrote:
> 
> > > Sounds like dropping base.linked and making previous optional would 
> > > address the problem more effectively.  Also, do we need to keep 
> > > policy.kern after successful installation of policy.N?  If 
> > not, we can 
> > > have libsemanage unlink it automatically after installation.
> > 
> > Same question for any other file regenerated by every commit, 
> > although we may not get much of a savings from the others.
> > file_contexts.template, file_contexts, and netfilter_contexts 
> > are the most obvious ones.
> > 
> 
> Karl suggested that we can compress the policy packages but not the
> kernel policy. As long as this isn't a policy package format change
> (eg., the policy packages in /usr/share/selinux are the same they've
> always been) and it is only libsemanage manipulating the files in the
> store I'm fine with that. The module store is a private resource of
> libsemanage so nothing else should be affected in any way by this. 
> 

Making semodule recognize bzipped files should be pretty simple as well
- why wouldn't we do that to save space in /usr/share/selinux?

> This will slow down some otherwise cheap operations such as semodule -l,
> rather than just opening the files and reading the policy name it'll
> have to decompress them first, I'm not sure what the performance cost
> will be.. Perhaps this should be configurable as well. 
> 

If we make printing the version optional we should be able to do this
with only name mangling on the file names in the module directory. We
should probably make it possible just to get a list of module names
anyway to facilitate scripting.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  parent reply	other threads:[~2006-11-09 18:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-09 13:50 I would like to propose that we add compression to handle all policy files on disk Daniel J Walsh
2006-11-09 14:34 ` Joshua Brindle
2006-11-09 15:13   ` Stephen Smalley
2006-11-09 15:23     ` Stephen Smalley
2006-11-09 15:55       ` Joshua Brindle
2006-11-09 17:00       ` I would like to propose that we add compression to handle allpolicy " Joshua Brindle
2006-11-09 17:49         ` Daniel J Walsh
2006-11-09 18:43         ` Karl MacMillan [this message]
2006-11-09 18:50           ` I would like to propose that we add compression to handleallpolicy " Joshua Brindle
2006-11-09 19:11             ` Karl MacMillan
2006-11-09 19:47               ` I would like to propose that we add compression tohandleallpolicy " Chris Stone
2006-11-09 21:01           ` I would like to propose that we add compression to handle allpolicy " Stephen Smalley
2006-11-09 21:10             ` Stephen Smalley
2006-11-09 21:54             ` Karl MacMillan
2006-11-09 22:05               ` Stephen Smalley
2006-11-13 18:27                 ` Karl MacMillan
2006-11-13 18:40                   ` Joshua Brindle
2006-11-14 14:45             ` Daniel J Walsh
2006-11-14 15:13               ` Joshua Brindle
2006-11-14 16:17                 ` Karl MacMillan
2006-11-09 20:59         ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1163097830.32083.52.camel@localhost.localdomain \
    --to=kmacmillan@mentalrootkit.com \
    --cc=dwalsh@redhat.com \
    --cc=jbrindle@tresys.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.