| 1 |
James Smith wrote: |
| 2 |
|
| 3 |
>Jan 26 16:30:29 [kernel] audit(1138318229.114:51): avc: denied { search } |
| 4 |
>for pid=4137 comm="apache2" name="mysqld" dev=hda3 ino=269837 |
| 5 |
>scontext=system_u:system_r:httpd_t |
| 6 |
>tcontext=system_u:object_r:mysqld_var_run_t tclass=dir |
| 7 |
>Jan 26 16:30:46 [kernel] audit(1138318246.947:54): avc: denied |
| 8 |
>{ name_connect } for pid=20815 comm="apache2" dest=80 |
| 9 |
>scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:http_port_t |
| 10 |
>tclass=tcp_socket |
| 11 |
> |
| 12 |
>Here are the two that seem to be most common. |
| 13 |
> |
| 14 |
>Thanks again. |
| 15 |
> |
| 16 |
>James |
| 17 |
> |
| 18 |
> |
| 19 |
I think your problem lies somewhere else. I see httpd_t tryes to access |
| 20 |
the mysql server. This is, I think, because you use mod_php. mod_php |
| 21 |
runs whit in the apache memory space. So this is why is looks like |
| 22 |
apache is trying to access mysql. |
| 23 |
This is not secure. To overcome this, you can run php as a cgi program. |
| 24 |
This is slower, but then apache wil exec php the proper way, which cause |
| 25 |
the php to run in the php_t. And the php_t shoul have access to the |
| 26 |
mysqld_var_run_t (probably the mysqld.sock). Then you can also use |
| 27 |
suexec2 to run the scripts as proper users and not as the apache user. |
| 28 |
|
| 29 |
Mivz |
| 30 |
-- |
| 31 |
gentoo-hardened@g.o mailing list |
Archives