From: domg472@gmail.com (Dominick Grift) Date: Sun, 13 Feb 2011 18:50:13 +0100 Subject: [refpolicy] Fwd: Re: Unexpected user_u permission denied for httpd_user_content_t Message-ID: <4D5819D5.8040308@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----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 To: Simon Peter Nicholls 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-----