From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 11 Dec 2012 09:31:10 -0500
Subject: [refpolicy] [PATCH 3/3] Implement X Desktop Group
In-Reply-To: <1355229303.1797.115.camel@localhost>
References: <1352116515-21046-1-git-send-email-dominick.grift@gmail.com>
	<1352116515-21046-4-git-send-email-dominick.grift@gmail.com>
	<1354194543.20999.3.camel@localhost> <50B76876.3010305@tresys.com>
	<1354198592.20999.5.camel@localhost> <50B8C429.3090901@tresys.com>
	<1354294882.12168.11.camel@localhost>
	<50B911B4.4020708@redhat.com> <50C17637.6040801@tresys.com>
	<1355229303.1797.115.camel@localhost>
Message-ID: <50C743AE.30208@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 12/11/2012 7:35 AM, grift wrote:
> On Thu, 2012-12-06 at 23:53 -0500, Christopher J. PeBenito wrote:
>> On 11/30/2012 3:06 PM, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 11/30/2012 12:01 PM, grift wrote:
>>>> On Fri, 2012-11-30 at 09:35 -0500, Christopher J. PeBenito wrote:
>>>>> On 11/29/12 09:16, grift wrote:
>>>>>> On Thu, 2012-11-29 at 08:51 -0500, Christopher J. PeBenito wrote:
>>>>>>> On 11/29/12 08:09, grift wrote:
>>>>>>>> Are we ready to make a decision yet with regard to the two
>>>>>>>> outstanding issues?
>>>>>>>>
>>>>>>>> - best type names? (my preference user_data_home_t,
>>>>>>>> user_config_home_t, user_cache_home_t)
>>>>>>>
>>>>>>> replace user with xdg, e.g. xdg_config_home_t.
>>>>>>>
>>>>>>>> - should be label ~/.local/share with the xdg data home type or
>>>>>>>> ~/.local ( my preference ~/.local/share)
>>>>>>>>
>>>>>>>> But i will go with whatever in the end
>>>>>>>
>>>>>>> Here's another option to consider:
>>>>>>>
>>>>>>> $HOME/.local  -d  gen_context(system_u:object_r:xdg_local_home_t,s0)
>>>>>>> $HOME/.local/share(/.*)?
>>>>>>> gen_context(system_u:object_r:xdg_data_home_t,s0)
>>>>>>>
>>>>>>> and then treat xdg_local_home_t similar to user_home_dir_t and
>>>>>>> filetrans everything under it.  Then the named filetrans for
>>>>>>> ~/.local/share will work right on top of any of the other random dirs
>>>>>>> that pop up under there.
>>>>>>
>>>>>> I understand your reasoning but i am not confident about the type name
>>>>>> "xdg_local_home_t" and i am also not confident that this type should
>>>>>> be declared in the xserver policy module
>>>>>>
>>>>>> how about we use local_home_t and declare it in the userdomain module?
>>>>>
>>>>> I'm unclear why you disagree.  It seems to make sense that 1. this
>>>>> standard is defined by the X desktop group, so xdg doesn't seem so bad to
>>>>> have in the type name.  2. I don't think it makes sense in userdomain
>>>>> because this standard applies to X desktops, so if you don't have an
>>>>> xserver, theres no need for these definitions.
>>>>>
>>>>
>>>> As far as i can see ~/.local is not part of the X desktop group although it
>>>> depends on it for ~/.local/share (data dir)
>>>>
>>>> userdomain might indeed not be a optimal alternative place to declare a
>>>> type for .local but i am not confident that xserver is either.
>>>>
>>>> What i understand is , is that ~/.local is "a place where users can install
>>>> apps with a prefix inside $HOME"
>>>>
>>>> I imagine one could have a headless server without X or the xserver policy
>>>> and still use ~/.local to "install apps with a prefix inside $HOME"
>>>>
>>>> But that is my view and i do not mind going your way. It is not such a big
>>>> deal.
>>>>
>>>> My patch v3 declares xdg_local_home_t is xserver module
>>>>
>>>>
>>> python uses ~/.local
>>
>> Yuck.  Well I guess that makes local_home_t make sense for ~/.local and xdg_data_home_t for ~/.local/data.  Then local_home_t could be declared in userdomain.
>>
>
> Agreed on the point above
>
> Another different point with regard to the actual XDG types. Would you
> oppose a separate policy module called xdg?
>
> I prefer that over using xserver policy module
>
> My concern is mainly because of the xdg runtime dir. It is not directly
> related to xserver.
>
> If we use a separate policy module for the xdg types then we have a
> little insurance that we do not run into any unneeded dependencies in
> the future.

I think it depends on the cleanliness of the implementation.  Can you do a partial implementation, say implement the support for one of the types?

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com