From: simon@mintsource.org (Simon Peter Nicholls)
Date: Sat, 12 Feb 2011 18:04:13 +0100
Subject: [refpolicy] Unexpected user_u permission denied for
	httpd_user_content_t
Message-ID: <4D56BD8D.70804@mintsource.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Is it known behaviour that user_u logins get locked out of their own web 
content?

If I login as a regular default login, I get user_u:

$ id -Z
user_u:user_r:user_t

I now want to start working up some web content, so I create the regular 
top level folder:

$ mkdir public_html

And see in the message log that restorecond has relabelled it for me. 
httpd_enable_homedirs is on:

restorecond: Reset file context /home/user/public_html: 
user_u:object_r:user_home_t->user_u:object_r:httpd_user_content_t

So far so good. I'll enter that directory so I can work up some HTML:

$ cd public_html
-bash: cd: public_html: Permission denied

Oops. I can't even list the attributes of the directory without having 
sysadm_r for example.

So at this point my user is already locked out of their own content, 
which doesn't feel right to me. Policy implementation aside, the access 
granted to Apache for using these files should be in addition to 
established permissions, not instead of.

Is this a known "rough edge" with refpolicy, or is this expected to work?

It's important for my situation, thinking ahead to distributed web 
deployment, that particular logins via SSH have management access to web 
content by default, without the need to switch roles to do so.

Thanks.