From: dwalsh@redhat.com (Daniel J Walsh)
Date: Mon, 07 Jan 2013 11:35:32 -0500
Subject: [refpolicy] Interfaces in refpolicy.
In-Reply-To: <1357575912.4082.1.camel@localhost>
References: <50EADFDB.5040507@redhat.com> <50EAE50D.4070409@tresys.com>
	<1357575912.4082.1.camel@localhost>
Message-ID: <50EAF954.1080707@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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

On 01/07/2013 11:25 AM, Dominick Grift wrote:
> On Mon, 2013-01-07 at 10:09 -0500, Christopher J. PeBenito wrote:
>> On 01/07/13 09:46, Daniel J Walsh wrote:
>>> We were have a side talk between Miroslav, Dominick and me about
>>> interfaces.
>>> 
>>> Dominick has merged lots of new policy from Fedora in to the contrib
>>> directory of refpolicy but he has been only including the interfaces
>>> that are actually used.  This has been the traditional way Chris has
>>> accepted interfaces into the upstream project.  (Other then _admin and
>>> _domtrans).  This is causing Miroslav problems merging in the lastest
>>> upstream back into Fedora, since Fedora has many interfaces defined
>>> that other domains are not currently using.
>>> 
>>> I believe that we should have a standard that each file type defined in
>>> a policy.
>>> 
>>> For example
>>> 
>>> getattr_dir read_dir getattr_file read_file rw_inherited_file 
>>> manage_file
>> 
>> I thought that we had agreed that doing this was generally acceptable
>> years ago?  That being said, I don't think these make sense for /all/
>> file types.  e.g. there should be no user_home_dir_t files.  Similarly, a
>> different set would apply for device nodes.
>> 
>>> The current mechanism where we don't have a comprehensive list can
>>> cause two problems for policy writers.
>> 
>> If you want a pretty comprehensive list, the policy pattern macros would
>> be a good place to start creating one, IMO.  We don't have to make
>> corresponding interfaces of all of those, but they do have the correct
>> access concepts and verbs to use in the interface names.
>> 
> 
> ok i saved this e-mail in my documentation folder for reference and will 
> apply what is discussed from now on
> 

Great.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDq+VQACgkQrlYvE4MpobPmhgCePOtH7lxZiiY3MFNXg1ybYuYk
nlMAoNtNBtqLXLePtPVivDWeUSWlc21I
=I6DT
-----END PGP SIGNATURE-----