From: eparis@parisplace.org (Eric Paris) Date: Wed, 16 Feb 2011 12:50:43 -0500 Subject: [refpolicy] [ access_vectors patch 1/2] Add access vectors: audit_access, read_policy. In-Reply-To: <4D5C0E3A.1050401@gmail.com> References: <20110214204329.GA9388@localhost.localdomain> <1297878201.27031.44.camel@moss-pluto> <4D5C0E3A.1050401@gmail.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, Feb 16, 2011 at 12:49 PM, Dominick Grift wrote: > -----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. I know dan has a patch in rawhide that does it right....