From: dominick.grift@gmail.com (Dominick Grift)
Date: Tue, 27 Nov 2012 14:27:10 +0100
Subject: [refpolicy] [PATCH 3/3] Implement X Desktop Group
In-Reply-To: <50B4BDE4.4080703@tresys.com>
References: <1352116515-21046-1-git-send-email-dominick.grift@gmail.com>
	<1352116515-21046-4-git-send-email-dominick.grift@gmail.com>
	<50B39A4B.6000905@tresys.com>
	<1353950589.10744.5.camel@x220.mydomain.internal>
	<50B4BDE4.4080703@tresys.com>
Message-ID: <1354022830.2379.5.camel@x220.mydomain.internal>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, 2012-11-27 at 08:19 -0500, Christopher J. PeBenito wrote:
> On 11/26/12 12:23, Dominick Grift wrote:
> > On Mon, 2012-11-26 at 11:35 -0500, Christopher J. PeBenito wrote:
> >> Overall, I'm ok with this, but have a couple questions:
> 
> Is there a particular reason you took this off list, or did you forget to reply-all?

Nope, i guess i did not hit reply-to-all. I have Cc'd refpolicy list
this time

> >> On 11/05/12 06:55, Dominick Grift wrote:
> >>> Add file context specifications for ~/.cache(/.*)? (user_cache_home_t),
> >>> ~/.config(/.*)? (user_config_home_t) and ~/.local/share(/.*)?
> >>> (user_data_home_t)
> >>
> >> I'm not sure that user_data_home_t is the best name.  I thought about user_local_home_t, but thats vague too.  Sven has been putting forward a patch for this stuff for a while too, and I'm thinking the it might make sense to have xdg in the type names.  
> > 
> > i dont mind the name just ell me which one you want. i personally like
> > this best but i have no problem with changing it
> 
> I don't have a specific idea, I was hoping for some feedback on-list.
> 

Ok i have Cc'd the list this time so that others can chime in.
I am fine with whatever we can get consensus on

> >>> There is a little issue with user_data_home, this is content for
> >>> ~/.local/share and as per xdg specification "share" is the user data
> >>> root dir instead of ~/.local, that means that the type transition
> >>> happens on user home content instead of user home dir. this makes it a
> >>> bit more prone to error since all directories named share created by
> >>> xserver_restricted_role callers in generic user home content
> >>> directories will be created with user_data_home_t. We could consider
> >>> using ~/.local instead
> >>
> >> It seems that .local would probably be a better idea, since it keeps errors down.  I looked on my system, and all I have in ~/.local is share anyway.
> >>
> > 
> > well i have for example ~/.local/bin
> > 
> > Again i am fine with both let me know what you want
> 
> Do you have any other examples?  Its unclear what is best.
> 

No, not currently. Its just that xdg spec is pretty clear about the
location of the data dir:  .local/share, so i assume that if they
meant .local, that they would have specified that instead

> >> [cut]
> >>> diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> >>> index 9bc86a0..a42f9bc 100644
> >>> --- a/policy/modules/services/xserver.te
> >>> +++ b/policy/modules/services/xserver.te
> >>> @@ -49,6 +49,11 @@ gen_tunable(xserver_object_manager, false)
> >>>  
> >>>  attribute x_domain;
> >>>  
> >>> +# X Desktop Group
> >>> +attribute xserver_user_cache_home_content_type;
> >>> +attribute xserver_user_config_home_content_type;
> >>> +attribute xserver_user_data_home_content_type;
> >>> +
> >>>  # X Events
> >>>  attribute xevent_type;
> >>>  attribute input_xevent_type;
> >>
> >> I'm unclear what the purpose of these attributes will be.  Do you expect to have interfaces that work on these?
> > 
> > 
> > we could leave those out for now but i think at some point some domains
> > will probably need access to all cache, config and data content types
> > rather then just the generic or a single private type
> 
> I'd prefer to leave it out.  Its easy enough to add.
> 

True, ok will remove that in a new patch when we figure out how to deal
with the other issues