[refpolicy] Fwd: Re: Unexpected user_u permission denied for httpd_user_content_t

[refpolicy] Fwd: Re: Unexpected user_u permission denied for httpd_user_content_t

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



- -------- Original Message --------
Subject: Re: [refpolicy] Unexpected user_u permission denied for
httpd_user_content_t
Date: Sun, 13 Feb 2011 18:35:24 +0100
From: Dominick Grift <domg472@gmail.com>
To: Simon Peter Nicholls <simon@mintsource.org>

On Sun, Feb 13, 2011 at 06:11:14PM +0100, Simon Peter Nicholls wrote:
> 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?

After having another look at refpolicy i have come to the conclusion
that apache_role() is in fact called for user_t, but that the
apache_role() has a bug as you rightfully pointed out, where calling
users are not allowed to manage httpd_user_content_t files, dirs and
lnk_files.

This seems to me like a bug in policy and so you could propose a patch
to this list with regard to this.

> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1YGdUACgkQMlxVo39jgT/TKACcCpDz0SLWbWgaLfMN4ADgDVMK
8xIAn1ZVoNz04AoSkXWk//r2l9pPnfkr
=mWgW
-----END PGP SIGNATURE-----

[refpolicy] Fwd: Re: Unexpected user_u permission denied for httpd_user_content_t

[Simon Peter Nicholls]

On 13/02/11 18:50, Dominick Grift wrote:
> After having another look at refpolicy i have come to the conclusion
> that apache_role() is in fact called for user_t, but that the
> apache_role() has a bug as you rightfully pointed out, where calling
> users are not allowed to manage httpd_user_content_t files, dirs and
> lnk_files.
>
> This seems to me like a bug in policy and so you could propose a patch
> to this list with regard to this.
Your patch works great, thanks.