All of lore.kernel.org
 help / color / mirror / Atom feed
From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] services_snmp.patch
Date: Thu, 04 Dec 2008 14:30:10 -0500	[thread overview]
Message-ID: <49382FC2.1080202@redhat.com> (raw)
In-Reply-To: <1228418815.903.88.camel@gorn>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher J. PeBenito wrote:
> On Thu, 2008-12-04 at 14:21 -0500, Daniel J Walsh wrote:
>> Christopher J. PeBenito wrote:
>>> On Wed, 2008-12-03 at 18:09 -0500, Daniel J Walsh wrote:
>>>> Christopher J. PeBenito wrote:
>>>>> On Tue, 2008-11-25 at 16:23 -0500, Daniel J Walsh wrote:
>>>>>> http://people.fedoraproject.org/~dwalsh/SELinux/F11/services_snmp.patch
>>>>>>
>>>>>> Communicates with virtual machines and xen machines
>>>>> I put the kernel_*_xen_state() calls in with the other xen_*() calls.
>>>>>
>>>>> Merged with some other tweaks.
>>>>>
>>>> But the xen stuff is optional while the kernel* calls are not.  So if
>>>> you used a policy without xen policy you still want to use the xen device.
>>> That doesn't make any sense to me.  Why would it still be using the xen
>>> proc interfaces if there is no xen?
>>>
>> If I have xen devices defined but use some policy other the xen, say
>> initrc_t, or myxen or expanded virt whatever.  The devices are defined
>> in device.te and other xen calls are defined in xen.if, they are not the
>> same.
> 
> But we're not talking about devices, we're talking about proc entries.
> I wouldn't expect those proc entries to exist except on a xen system, in
> which case you also need the xen policy.
> 
You would need policy but not necessarily the interfaces that are
defined in xen.if.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk4L8IACgkQrlYvE4MpobP3dgCguKA5tqeXcJobVIZ3XySQ5GyU
19cAoLVgDsklyeXzOLnJY3tNJpbNApWy
=w2PZ
-----END PGP SIGNATURE-----

  reply	other threads:[~2008-12-04 19:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-25 21:23 [refpolicy] services_snmp.patch Daniel J Walsh
2008-12-03 15:32 ` Christopher J. PeBenito
2008-12-03 23:09   ` Daniel J Walsh
2008-12-04 13:07     ` Christopher J. PeBenito
2008-12-04 19:21       ` Daniel J Walsh
2008-12-04 19:26         ` Christopher J. PeBenito
2008-12-04 19:30           ` Daniel J Walsh [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-08-26 22:21 Daniel J Walsh
2010-02-23 20:58 Daniel J Walsh
2009-11-12 22:00 Daniel J Walsh
2010-01-07 14:01 ` Christopher J. PeBenito
2009-03-05 17:04 Daniel J Walsh
2009-05-14 15:15 ` Christopher J. PeBenito
2008-10-14 19:33 Daniel J Walsh

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=49382FC2.1080202@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=refpolicy@oss.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.