On Tue, 2005-02-22 at 16:44 -0700, Tom Lisjac wrote:
>I was under the impression that mod_php and the webserver ran in the
>same context... so I'm not sure I understand the distinction SELinux
>would make between the server and the script.
You are correct; mod_php code does run in the same context as Apache
(i.e. httpd_t), because it runs in-process.
>Here's the avc that is generated. Apparently the write did occur and
>this was an attempt by the script to read the spellchecked file back.
>
>avc: denied { getattr } for pid=32122 exe=/usr/bin/aspell
>path=/tmp/spellkQimNQ dev=hda2 ino=326408
>scontext=root:system_r:httpd_sys_script_t
>tcontext=root:object_r:httpd_tmp_t tclass=file
Note however here that the source context is httpd_sys_script_t (not
httpd_t), which means it's a CGI script. CGI scripts by default run in
a separate context.
Are you really sure that you don't have an external CGI script being
run?
Perhaps what is happening here is that for some reason, when httpd_t
execs /usr/bin/aspell, a transition is happening to httpd_sys_script_t.
But from looking at the policy, I don't see any transition rules for
bin_t.
>I'm curious why the targeted policy allows the write but blocks reads from /tmp?
Because as best I can tell, the write was done by the main webserver
process, and the read is being attempted by a CGI script.
Consider the case where Apache keeps temporary data files containing
private information in /tmp; in general you don't want CGI scripts to be
able to read that.
>In any case, it appears that I should make the exception and allow the
>read. I made a huge mess when I started hacking the policy sources in
>FC2... is there a document or howto somewhere that describes the
>correct way to add a exception that will survive an rpm policy update?
You should probably upgrade to FC3; a huge amount of work has gone into
the policy (but we still have a lot more to do...).
