SELinux/httpd integration

[Colin Walters]

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.