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.