From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 15 Nov 2011 09:23:08 -0500
Subject: [refpolicy] [PATCH/RFC v3] Introduce xdg types
In-Reply-To: <20111115073337.GA28333@siphos.be>
References: <20111013140614.GA3116@siphos.be>
	<20111113203317.GA17650@siphos.be> <4EC17B88.1040006@tresys.com>
	<20111115073337.GA28333@siphos.be>
Message-ID: <4EC275CC.8010307@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 11/15/11 02:33, Sven Vermeulen wrote:
> On Mon, Nov 14, 2011 at 03:35:20PM -0500, Christopher J. PeBenito wrote:
>>> (1.) Enhance userdom_user_home_dir_filetrans with a fourth argument
>>>      (filename) and use that in its filetrans_pattern() call
>>> (2.) Enhance xdg.if with the xdg_*_home_filetrans statements that accomplish
>>>      something like 
>>>        userdom_user_home_dir_filetrans($1, xdg_cache_home_t, dir, ".cache")
>>>      for the xdg_cache_home_filetrans (others very related)
>>
>> These two are fine.  I've attached my working patch for interfaces with optional
>> parameters to support name filetrans.  I'm trying to decide (with CIL in mind)
>> if we really want interfaces with optional parameters.
> 
> As opposed to different interface names? Like using a _named_filetrans:
> userdom_user_home_dir_filetrans versus 
> userdom_user_home_dir_named_filetrans (just a hypothetical example) ?

Yes.

> I'm okay with either. If you were to allow optional parameters, you probably
> will end up with at most one optional parameter (if you have two, how would
> you allow having the second one set but not the first).

I don't have a compelling argument either way.  I suspect that if we did go the optional parameter route, the refpolicy->CIL compiler would have to convert optional parameter interfaces into to two CIL macros with different names anyway.

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