On Mon, 2004-11-22 at 17:37 -0500, Daniel J Walsh wrote:
> Our view of httpd_unified, is allow all httpd executables to have full
> access to all httpd content.
Hm. Well, this changes the scenarios in the Apache guide. The guide
had assumed that if you turned off httpd_enable_cgi, then httpd_t
couldn't change any files in the static file serving case. That's not
true if httpd_unified stays the way it is.
I guess what's kind of throwing a wrench into this whole thing is PHP,
since it runs in-process. So broadly there are two cases:
1) Without PHP/mod_python/etc., but using specific CGI scripts
2) With PHP/mod_python/etc.
Perhaps then what we want is a boolean to distinguish between these
cases, say httpd_builtin_scripting. When httpd_builtin_scripting is
enabled, we grant to httpd_t all the permissions that we were granting
to CGI scripts. We keep httpd_unified, and it means the same thing it
meant before: that httpd_sys_content_t is equivalent to
httpd_sys_script_rw_t and httpd_sys_script_exec_t.
Then if you enable both httpd_builtin_scripting and httpd_unified, your
Apache setup will likely work with most crazy PHP apps. They'll be able
to read/write all of the content.
The case of static files and external CGI scripts works with
httpd_unified enabled and httpd_builtin_scripting disabled.
And finally, the static file serving case works well with
httpd_builtin_scripting and httpd_enable_cgi disabled.
Does that make sense?
Incidentally, why do we have httpd_php_t? It looks rather vestigial.
|
