From: domg472@gmail.com (Dominick Grift) Date: Sat, 12 Feb 2011 20:35:58 +0100 Subject: [refpolicy] Unexpected user_u permission denied for httpd_user_content_t In-Reply-To: <4D56BD8D.70804@mintsource.org> References: <4D56BD8D.70804@mintsource.org> Message-ID: <20110212193557.GA3123@localhost.localdomain> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sat, Feb 12, 2011 at 06:04:13PM +0100, Simon Peter Nicholls wrote: > 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. 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. > > Thanks. > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110212/afbbe2ea/attachment.bin