From: gizmo@giz-works.com (Chris Richards)
Date: Tue, 27 Apr 2010 23:22:14 -0500
Subject: [refpolicy] [PATCH 1/1] Create new interface and type for
 managing /etc/udev/rules.d
In-Reply-To: <4BD6F60C.1010401@giz-works.com>
References: <1271399256-4177-1-git-send-email-gizmo@giz-works.com>	<1272373805.32279.237.camel@gorn>
	<4BD6F60C.1010401@giz-works.com>
Message-ID: <4BD7B7F6.8080405@giz-works.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 04/27/2010 09:34 AM, Chris Richards wrote:
> Actually, for that part, it might be smarter to submit a patch to Gentoo
> to change how the udev-postmount script works, now that I think a bit
> more about it.
>
>    
I've submitted a bug report to Gentoo, along with a patch modifying the 
behavior of the udev-postmount script so that it doesn't trip the 
alarms.  That renders the rest of this policy change more of a 
philosophical discusssion than an actual requirement.

Philosophically, should we really have udev_var_run_t managing files in 
/etc/udev/rules.d?

On the other hand, it isn't actually harming anything at the moment, so 
there's some argument to be made for the "if it ain't broke" school of 
thought.

My thought is to go ahead and change this.  It should be a low impact 
change.  Near as I can tell only the init script currently has access to 
udev_var_run_t, via the udev_manage_pid_files interface.  All other 
access is controlled with the udev policy, and amounts to manage dirs, 
manage files, manage links, and a filetrans.  But I might be missing the 
bigger picture here.  As an SElinux n00b, I'm open and interested in 
other thoughts.

Later,
Chris