From: domg472@gmail.com (Dominick Grift)
Date: Wed, 16 Feb 2011 18:49:46 +0100
Subject: [refpolicy] [ access_vectors patch 1/2] Add access vectors:
 audit_access, read_policy.
In-Reply-To: <1297878201.27031.44.camel@moss-pluto>
References: <20110214204329.GA9388@localhost.localdomain>
	<1297878201.27031.44.camel@moss-pluto>
Message-ID: <4D5C0E3A.1050401@gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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

On 02/16/2011 06:43 PM, Stephen Smalley wrote:

> 
> You can't insert permissions into the common definition without
> perturbing the permission values for subsequent permissions in the
> per-class definitions.  That isn't a problem for recent kernels with
> dynamic class/permission mapping support, but it will break
> compatibility for older kernels.  What you can do instead is to add new
> permissions, like audit_access, to the end of each per-file class, and
> then kernels with the dynamic class/perm mapping support will
> transparently map the values.
> 

Thanks for the clarification, was wondering already about why it was
added the way it was. Issue with execmod, open permission in refpolicy
is that its not added to all classes that support it currently.

I guess i will submit a retry.

>>  
>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1cDjoACgkQMlxVo39jgT/AtwCcCmU8Fq7rVHCpYzwvYItUs/Il
w6wAn1orGBMblcXOHCGXLsnUBESU9x8t
=pJYW
-----END PGP SIGNATURE-----