From: dominick.grift@gmail.com (Dominick Grift)
Date: Mon, 11 Feb 2013 20:56:11 +0100
Subject: [refpolicy] [PATCH/RFC] Reintroduce httpd_user_content_type and
 httpd_user_script_exec_type attributes
In-Reply-To: <1360612300.2559.28.camel@d30>
References: <20130211190233.GA11417@siphos.be>
	<1360611019.2559.22.camel@d30> <20130211193354.GA12406@siphos.be>
	<1360612300.2559.28.camel@d30>
Message-ID: <1360612571.2559.30.camel@d30>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 2013-02-11 at 20:51 +0100, Dominick Grift wrote:
> On Mon, 2013-02-11 at 20:33 +0100, Sven Vermeulen wrote:
> > On Mon, Feb 11, 2013 at 08:30:19PM +0100, Dominick Grift wrote:
> > > > The httpd_user_content_type and httpd_user_script_exec_type attributes were
> > > > erroneously removed a while ago, but while trying to reintroduce them I did
> > > > notice that they were removed because there was no way for users to actually
> > > > use them (or I'm completely misreading the policy code).
> > > 
> > > I still do not understand the purpose of this. Is there some actual need
> > > for this? I deprecated the interface because it was unused and i could
> > > not see a convincing need for it to exist.
> > > 
> > > Can you enlighten me? What issue are you facing? Who, other than the
> > > user needs to be able to manage user content/script dirs, files and
> > > symlinks?
> > 
> > I'll have to ask Christopher, I made this patch as a result of our previous
> > thread on this matter (where I initially changed a deprecated function to
> > reflect the removal of these types):
> > 
> > http://oss.tresys.com/pipermail/refpolicy/2013-January/006255.html
> > 
> > Wkr,
> > 	Sven Vermeulen
> 
> 
> I read that thread and do you have a actual case where useradd creates
> ~/public_html?
> 
> I do not see a need for useradd to be able to create that
> 
> But even so then it still needs no access to httpd_user_content files
> and symlinks or any httpd_user_script_exec_t content
> 
> Can you not just create a httpd_manage_user_content_dirs, with something
> like the following:
> 
> userdom_rw_user_home_dirs($1)
> allow $1 httpd_user_content_t:dir manage_dir_perms;
>  
> 

There is no need for attributes here

user content is:

httpd_user_content_t
httpd_user_content_rw_t
httpd_user_content_ra_t
httpd_user_htaccess_t
httpd_user_script_exec_t