Acerca de los owners y PHPsuExec

[JJRC]

Les comento que tengo varios sitios cms (joomla, drupal, wordpress, etc) corriendo en mi VPS. He notado que algunos directorios y archivos tienen como propietario (owner) nobody nobody en vez del user user o lo que corresponda. Por este motivo no puedo editar archivos desde mi cliente FTP.
Consultando a mi proveedor de hosting me dijo algo que no llegué a comprender muy bien relacionado con PHPsuExec.
Me dice que PHP actualmente se ejecuta como módulo de apache y que para hacer lo que necesito requiero que se ejecute un PHPsuExec o algo así.
¿Qué sugieren Uds.?¿Cuál es la configuración óptima para esto? No quisiera tener riesgos de seguridad. Simplemente quiero que las cosas funcionen correctamente ya que intenté desinstalar un par de extensiones de joomla y no me deja porque no hay permisos para remover ciertos archivos que estan como nobody nobody.
Saludos,

[Apolo]

Hola,

En verdad me gustaría saber el mensaje exacto que le enviaste a tu proveedor, así como su respuesta. Y también el nombre del proveedor, pues así como lo expresas, se están mezclando asuntos diferentes.

A cambio de tu respuesta, con mucho gusto te orientaré al respecto.

Saludos,

[JJRC]

Mi consulta fue que necesitaba todos los archivos usando el nombre de la cuenta en vez de nobody nobody.
Y esta fue la respuesta:

PHP of your VPS is compiled as non-PHPsuExec. At present PHP is running as an apache module ( non-phpsuexec) and this requires directories to have 777 permission for uploading/editing.

That is, when PHP runs as an Apache Module it executes as the user/group of the webserver which is usually "nobody". Under this mode, files or directories that you require your php scripts to write to need to have 777 permissions (read/write/execute at user/group/world level).

This is not very secure because besides allowing the webserver to write to the file it also allows anyone else to read or write to the file.

PHPsuExec:

PHPsuExec fixes all this because it requires php to be run as the file owner's username.With PHP running as CGI with suexec enabled your php scripts now execute under your user/group level. Files or directories that you require your php scripts to write to no longer need to have 777 permissions.

In fact, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a 500 internal server error when attempting to execute them to protect you from someone abusing your scripts. Your scripts and directories can have a maximum of 755 permissions (read/write/execute by you, read/execute by everyone else).

If you need to enable PHPsuExec on the server, then you need to note the following points:(if any of the following requirements fail, your site will show up an internal server error).

1. The php script that you are attempting to execute has permissions of no more than 755 - 644 will work just fine normally, this is not something that will need to be changed in most cases.

2. The permission of the directory that the script resides within is set to a maximum of 755. This also includes directories that the script would need to have access to also.

3. You shouldn't have a .htaccess file with php_values within it. They will cause a 500 Internal server error, when attempting to execute the script.

4.The php_values will need to be removed from your .htaccess file and a php.ini put in its place, containing the php directives as explained above.

Please let us know, if you want to enable PHPsuExec.

[Apolo]

Bien, la vida sería mucho más fácil si los desarrolladores de esos scripts usaran métodos más adecuados (como un usuario FTP) para la instalación de esos módulos y componentes. Creo que en Joomla, a partir de la versión 1.5 ya existe esa posibilidad.

Al instalarlo usando un usuario FTP, los archivos quedan asignados al propietario de esa cuenta. Al instalarlo como lo hacen actualmente, los archivos quedan asignados al usuario "nobody" que es el que corre Apache. Y por ello se presentan los inconvenientes que mencionas, cuando PHP se encuentra instalado como módulo de Apache.

Para solucionarlo dejando las cosas tal y como están, es cuestión de correr un comando similar a...

chown -R usuario.usuario /ruta/al/directorio

Pide asistencia a tu proveedor con la utilización de ese comando, si tienes alguna duda.

O podrías optar por la opción que ellos te ofrecen, teniendo en cuenta esas observaciones, que generalmente se solucionan de manera muy fácil cuando pasas de mod_php a PHPsuExec. El rendimiento de tu servidor va a disminuir un poco debido a la forma en que funciona PHP como CGI, pero no encuentro mayores inconvenientes al optar por esa opción.

Saludos,

[JJRC]

Esa disminunción de rendimiento te parece que puede ser percibida?
Estoy usando un VPS con 398MB de Ram

[Apolo]

Hola,

Algunos cálculos que he leído dicen que entre 4% y 10%, pero hay muchas variables de entorno en juego, así que difícil decirlo con exactitud. Podría ser mucho menos que eso o un poco más que eso.

Saludos,

[JJRC]

Gracias por tu ayuda.
Te hago una consulta más y dejo de molestar.
He leído por ahí que en el caso de extensiones que requieran algún directorio con chmod777 basta con dejarlo en 755. Hasta aquí todo bien con los directorios, pero esto también se aplica a archivos?
Es decir, si necesito escritura en archivos puedo usar chmod755 en ellos o lo correcto sería usar 644?

[Apolo]

Hola,

Cuando PHP está instalado como CGI no puedes tener archivos o directorios con permisos de escritura globales.

755 te funcionará bien para directorios y 644 te funcionará bien para archivos. Como todo se hace desde el mismo usuario propietario, ya no se necesita tener 777 si desde la aplicación se necesita escribir en ese archivo o directorio.

Saludos,

[EstudioDsign]

por fin me aclararon un poco lo de suphp