All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Hally <rhally@mindspring.com>
To: Daniel J Walsh <dwalsh@redhat.com>, SELinux <selinux@tycho.nsa.gov>
Subject: Re: We are attempting once again to split policy out into individual RPMS.
Date: Tue, 02 May 2006 12:13:42 -0400	[thread overview]
Message-ID: <44578536.9060106@mindspring.com> (raw)
In-Reply-To: <44576B91.8060607@redhat.com>

Daniel J Walsh wrote:
<snip>

> 
> We need the ability for RPM to be able to write a file context on disk 
> without the kernel verifying it.  The kernel should treat this as an 
> unlabeled_t file. the same way it would if I ran
> 
> semodule -i XYZ.pp
> restorecon /usr/bin/XYZ
> semoduel -e XYZ
> 
> I don't think this is an unreasonable request to allow rpm_t to have the 
> privilege of writing the "invalid" context to disk.
> 
> Secondly the rpm team would like to be able to execute the equivalent of 
> matchpathcon(XYZ.pp)  IE be able to extract the FC file mapping from the 
> policy package and combine it with the on disk representation to 
> determine the file context to associate with the new files being put on 
> disk.
> 
> At the end of the rpm install, postinstall would do an semodule -i XYZ.pp.
> 
> We want to start out with just a couple of packages shipping policy to 
> prove the technology and then to allow third parties to ship using this 
> method.
> 
> Dan


What if the files being installed were already labeled with the context?
I.e after the files are built but before being packaged into the rpm, 
the context is applied to the file.

Richard


--
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-05-02 16:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-02 14:24 We are attempting once again to split policy out into individual RPMS Daniel J Walsh
2006-05-02 15:01 ` Joshua Brindle
2006-05-02 15:16   ` Jeremy Katz
2006-05-02 15:33     ` Joshua Brindle
2006-05-02 15:48       ` Jeremy Katz
2006-05-03 15:15         ` Karl MacMillan
2006-05-03 19:02           ` Joshua Brindle
2006-05-03 19:06             ` Jeremy Katz
2006-05-03 19:07             ` Karl MacMillan
2006-05-03 21:14               ` Joshua Brindle
2006-05-04  9:01                 ` Thomas Bleher
2006-05-04 19:18                   ` Thomas Bleher
2006-05-02 15:12 ` Stephen Smalley
2006-05-02 15:27   ` Jeremy Katz
2006-05-02 16:26     ` Stephen Smalley
2006-05-02 16:29       ` Paul Nasrat
2006-05-02 16:53         ` Stephen Smalley
2006-05-02 17:42       ` Stephen Smalley
2006-05-02 17:53         ` Jeremy Katz
2006-05-03 15:08       ` Karl MacMillan
2006-05-03 15:33         ` Daniel J Walsh
2006-05-03 15:41           ` Karl MacMillan
2006-05-02 15:27   ` Paul Nasrat
2006-05-02 16:13 ` Richard Hally [this message]

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=44578536.9060106@mindspring.com \
    --to=rhally@mindspring.com \
    --cc=dwalsh@redhat.com \
    --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.