All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Karl MacMillan <kmacmillan@mentalrootkit.com>,
	Joshua Brindle <jbrindle@tresys.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: Tue, 14 Nov 2006 09:45:43 -0500	[thread overview]
Message-ID: <4559D697.4080800@redhat.com> (raw)
In-Reply-To: <1163106106.12241.399.camel@moss-spartans.epoch.ncsc.mil>

Stephen Smalley wrote:
> On Thu, 2006-11-09 at 13:43 -0500, Karl MacMillan wrote:
>   
>> 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?
>>     
>
> Why do we need to keep /usr/share/selinux/$SELINUXTYPE/*.pp around
> _after_ a successful run of semodule from %post?  Why not just remove
> them after installation?  And move enableaudit.pp into a separate -debug
> package.
>
>   
Because that is not the way RPM works.  :^(  Anything in the payload 
gets left on disk, Removing them in the post would be bad and would 
screw up rpm -V.

I am planning on compressing them, and changing the post install to 
uncompress into a temp dir during install.  That way it will at least be 
less of a problem.

That along with elimination of some of the stuff in modules subdirs 
should save us a lot of space, until we get some consensus on 
compression of the pp files.

Dan

--
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-14 14:45 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
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 [this message]
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=4559D697.4080800@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=jbrindle@tresys.com \
    --cc=kmacmillan@mentalrootkit.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.