2011-02-13 17:50:13

by domg472

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

-----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 <[email protected]>
To: Simon Peter Nicholls <[email protected]>

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-----


2011-02-14 10:33:35

by simon

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

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.