From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 11 Nov 2009 09:46:33 -0500
Subject: [refpolicy] [PATCH] make consolekit_t a confined X client
In-Reply-To: <4AF9FD72.1040501@tycho.nsa.gov>
References: <4AEB72FE.60803@tycho.nsa.gov>
	<1257170929.17520.20.camel@gorn.columbia.tresys.com>
	<4AEF0907.1040806@redhat.com>  <4AF9FD72.1040501@tycho.nsa.gov>
Message-ID: <1257950793.17482.15.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, 2009-11-10 at 18:55 -0500, Eamon Walsh wrote:
> On 11/02/2009 11:29 AM, Daniel J Walsh wrote:
> > On 11/02/2009 09:08 AM, Christopher J. PeBenito wrote:
> >   
> >> On Fri, 2009-10-30 at 19:13 -0400, Eamon Walsh wrote:
> >>     
> >>> Note: I don't know what to put for the third argument to xserver_user_x_domain_template.
> >>> tmpfs_t?  user_tmpfs_t?  Why does this template have a tmpfs argument anyway?
> >>>       
> >> Its designed for full X apps that use the display for their tmpfs type
> >> used for the shm.  Does consolekit need a subset of whats in
> >> xserver_user_x_domain_template?
> >>     
> 
> In the case of the consolekit ck-get-x11-server-pid program, it does not
> create any shared memory segments, so no it does not need the tmpfs
> argument.
> 
> The reason the tmpfs argument is there is so the X server can get
> permission to read the shared memory segment created by the domain.  I
> wonder if the X server could simply be granted access to all such
> segments in a blanket typealias rule.  This would eliminate the need for
> the tmpfs argument.
> 
> Barring that, I think it might be worthwhile to separate out the tmpfs
> stuff into a separate interface.  I'll see if I can put something together.

As I mentioned earlier, the concept for the interface was for usage on
full fledged X apps that have windows, etc.  Perhaps we should pause for
a moment to establish what types of X apps there are?


-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150