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.
