All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Steve Lawrence <slawrence@tresys.com>,
	Dominick Grift <dominick.grift@gmail.com>
Cc: SELinux List <selinux@tycho.nsa.gov>
Subject: Re: [RFC] Source Policy, CIL, and High Level Languages
Date: Fri, 18 Jul 2014 10:30:42 -0400	[thread overview]
Message-ID: <53C92F92.6070607@tycho.nsa.gov> (raw)
In-Reply-To: <53C91A48.7040704@tresys.com>

On 07/18/2014 08:59 AM, Steve Lawrence wrote:
> There isn't currently a way to extract policy from the store, but that
> has been a use case that has been discussed in the past. Something like
> the following could be useful:
> 
> semodule --priority 400 --extract foo # outputs to foo.<hll>
> edit foo.<hll>
> semodule --priority 500 --install foo.<hll>
> 
> So there could be cases in the future where it could be convenient to
> keep the HLL files around.

Sure, for source modules.  For pp files, though?

> Another option to reduce disk usage could be to disable caching of the
> CIL files (right now, we only have an option to ignore the cached
> files). This way, the user could still do the above and edit hll files
> without having to rely on them being accessible from somewhere else.
> Though, this would incur a penalty of having to recompile HLL files for
> every change (which in my tests, about doubles compilation time).

Seems less useful than being able to disable storage of the HLL files.
No penalty incurred, you just have to know that you won't need them
again or that they will remain available externally.

>> More generally, if the user knows that the hll module is going to be
>> saved elsewhere, then there is no reason to retain a copy in the policy
>> store, so having the option of dropping the hll version, either for all
>> modules or for specific modules, seems useful.
> 
> Do you see this feature as necessary for this patchset to be upstreamed,
> or is this something we could add as a later update?

Not absolutely required, just wondering if we might encounter issues
with migration on some systems due to insufficient space.  We'll
actually have 3 copies of each module, 2 pp files (one still in
/etc/selinux/targeted/modules, not deleted by the migration script) and
1 cil file.  Plus all of the copying that occurs during the transaction
and installation of the files (-> /var/lib/selinux/targeted/tmp, ->
/var/lib/selinux/tmp/targeted?, -> /etc/selinux/targeted).  Any idea
what the max storage requirement for successful migration relative to
the original size of the policy store?

  reply	other threads:[~2014-07-18 14:30 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-09 19:21 [RFC] Source Policy, CIL, and High Level Languages Steve Lawrence
2014-07-10  6:51 ` Dominick Grift
2014-07-10 12:19   ` Steve Lawrence
2014-07-10 12:35   ` Stephen Smalley
2014-07-10 12:52     ` Dominick Grift
2014-07-10 13:09       ` Dominick Grift
2014-07-10 13:12         ` Stephen Smalley
2014-07-10 13:26           ` Dominick Grift
2014-07-10 13:38             ` Stephen Smalley
2014-07-10 13:45               ` Dominick Grift
2014-07-11 15:02                 ` Steve Lawrence
2014-07-15 20:11                   ` Steve Lawrence
2014-07-10 15:02             ` Stephen Smalley
2014-07-11 17:20   ` Steve Lawrence
2014-07-14 16:48     ` Stephen Smalley
2014-07-14 16:53       ` Stephen Smalley
2014-07-14 17:08         ` Stephen Smalley
2014-07-14 17:12           ` Steve Lawrence
2014-07-14 17:49             ` Stephen Smalley
2014-07-15 19:56               ` Steve Lawrence
2014-07-16 14:16                 ` Stephen Smalley
2014-07-16 14:21                   ` Stephen Smalley
2014-07-16 14:26                     ` Stephen Smalley
2014-07-16 14:33                       ` Stephen Smalley
2014-07-16 15:11                         ` Steve Lawrence
2014-07-16 15:53                           ` Dominick Grift
2014-07-16 15:58                             ` Dominick Grift
2014-07-16 19:00                             ` Stephen Smalley
2014-07-17 13:49                               ` Steve Lawrence
2014-07-17 14:02                                 ` Stephen Smalley
2014-07-17 18:02                                 ` Stephen Smalley
2014-07-17 18:58                                   ` Steve Lawrence
2014-07-17 19:10                                     ` Stephen Smalley
2014-07-17 19:48                                       ` Stephen Smalley
2014-07-17 20:04                                         ` Steve Lawrence
2014-07-17 20:37                                           ` Stephen Smalley
2014-07-17 20:50                                             ` Daniel J Walsh
2014-07-17 20:52                                             ` Daniel J Walsh
2014-07-23 19:24                                               ` Stephen Smalley
2014-07-24 12:48                                                 ` Daniel J Walsh
2014-07-18 12:59                                             ` Steve Lawrence
2014-07-18 14:30                                               ` Stephen Smalley [this message]
2014-07-18 15:57                                                 ` Steve Lawrence
2014-07-22 15:05                                               ` James Carter
2014-07-18 14:13                                             ` Christopher J. PeBenito
2014-07-17 19:51                                       ` Steve Lawrence
2014-07-22 14:47                                     ` James Carter
2014-07-16 15:43                 ` Steve Lawrence
2014-07-14 17:33           ` Dominick Grift
2014-07-18 16:00   ` Steve Lawrence
2014-07-18 18:10     ` Stephen Smalley
2014-07-21 14:34       ` Steve Lawrence
2014-07-21 14:51         ` Stephen Smalley
2014-07-21 17:50           ` Steve Lawrence
2014-08-01 14:51             ` Steve Lawrence
2014-08-01 17:46               ` Stephen Smalley
2014-08-04 14:07                 ` Steve Lawrence
2014-08-18 22:37                 ` Steve Lawrence
2014-07-10 13:52 ` Stephen Smalley
2014-07-10 14:06   ` Dominick Grift
2014-07-10 14:09   ` Steve Lawrence
2014-07-10 14:58     ` James Carter
2014-07-10 13:59 ` Stephen Smalley
2014-07-10 14:53   ` Steve Lawrence
2014-07-10 14:11 ` Stephen Smalley
2014-07-10 14:13   ` Stephen Smalley
2014-07-10 14:17   ` Steve Lawrence
2014-07-10 14:20     ` Stephen Smalley
2014-07-10 14:23   ` Dominick Grift
2014-07-10 14:25     ` Stephen Smalley
2014-07-10 14:34       ` Stephen Smalley
2014-07-10 14:50         ` Dominick Grift
2014-07-10 14:43       ` Dominick Grift
2014-07-10 14:30 ` Stephen Smalley
2014-07-10 14:50   ` Stephen Smalley
2014-07-10 15:05     ` Steve Lawrence
2014-07-10 15:08       ` Stephen Smalley
2014-07-10 16:04   ` Steve Lawrence
  -- strict thread matches above, loose matches on Subject: below --
2014-04-29 14:59 Steve Lawrence
2014-05-01 12:38 ` Dominick Grift
2014-05-01 12:57   ` Steve Lawrence
2014-05-01 13:24     ` Dominick Grift
2014-05-01 13:27       ` Dominick Grift
2014-05-01 13:31         ` Dominick Grift
2014-05-01 14:01           ` Steve Lawrence

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=53C92F92.6070607@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=dominick.grift@gmail.com \
    --cc=selinux@tycho.nsa.gov \
    --cc=slawrence@tresys.com \
    /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.