From: simon@mintsource.org (Simon Peter Nicholls)
Date: Sun, 13 Feb 2011 18:11:14 +0100
Subject: [refpolicy] Unexpected user_u permission denied for
	httpd_user_content_t
In-Reply-To: <20110212193557.GA3123@localhost.localdomain>
References: <4D56BD8D.70804@mintsource.org>
	<20110212193557.GA3123@localhost.localdomain>
Message-ID: <4D5810B2.7030506@mintsource.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 12/02/11 20:35, Dominick Grift wrote:
> Whoops my previoussly reply assumed you were using a redhat distro 
> instead of plain refpolicy.
> So you will probably have to create a loadable module with the apache_role() called, preferable for guest_t/guest_r.

I tried this just now, and it didn't work. Looking through the Apache 
interface file, it looks like apache_role gives manage access to user_ra 
and user_rw content, but only relabelling for regular old 
httpd_user_content_t. I can verify my module enforces these perms, so 
the build process seems fine, but I'd rather not give more rights than 
desired of course.

Something like "allow guest_t httpdcontent : dir_file_class_set *;" 
allows me broad access to get up and running, but I'm curious what the 
underlying issue is with Apache policy. Should it be using typeattribute 
to flag httpd_user_content_t as a user manageable file, so that regular 
'allow' rules for user account file management can automatically pick it up?