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.
next prev 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.