OVH Community, your new community space.

Ayuda para paso a suPHP


Power
26/05/2010, 07:56
Hola,
Cita Publicado inicialmente por luis_sanz
supongo que a lo que se refiere Salteador.. que me corrija el si no es asi.

es que lo mismo da que sea nobody que pepito, vamos que si yo te subo un php a host de pepito o hago alguna inserccion de codigo a un script php de pepito, lo mismo me da, que sea nobody que pepito el que tenga autorizacion para mandar esos emails.

no se en seguridad, a que te refieres con lo de nobody y la funcion mail(), que conste que yo uso suPHP y estoy feliz con el, de echo de vez en cuando lo paso a fastcgi sin complicarme la vida en mas que un par de clics, solo por ir probando la carga que da uno y otro, pero DSO ni en pintura
¡¡¡ Ah, vale !!!
Ya entiendo lo que comentaba Salteador.
Gracias Luis_sanz por aclararlo.

La seguridad la veo en que ahora mirando los logs sé desde qué cuenta se ha enviado un email via web.
Antes todos eran desde nobody.

Saludos

luis_sanz
26/05/2010, 01:26
Cita Publicado inicialmente por Power
Hola,

Antes, con PHP, ejecutándose en modo DSO, el propietario del proceso de PHP era nobody y, por tanto era nobody quien utilizaba la función mail()

Saludos
supongo que a lo que se refiere Salteador.. que me corrija el si no es asi.

es que lo mismo da que sea nobody que pepito, vamos que si yo te subo un php a host de pepito o hago alguna inserccion de codigo a un script php de pepito, lo mismo me da, que sea nobody que pepito el que tenga autorizacion para mandar esos emails.

no se en seguridad, a que te refieres con lo de nobody y la funcion mail(), que conste que yo uso suPHP y estoy feliz con el, de echo de vez en cuando lo paso a fastcgi sin complicarme la vida en mas que un par de clics, solo por ir probando la carga que da uno y otro, pero DSO ni en pintura

Power
25/05/2010, 19:05
Hola,
Cita Publicado inicialmente por Salteador
Entonces es lo mismo que este activado, no funcionara igualmente.
Antes, con PHP, ejecutándose en modo DSO, el propietario del proceso de PHP era nobody y, por tanto era nobody quien utilizaba la función mail()

Ahora con PHP en modo suPHP, si hay una petición web a la cuenta pepito, el proceso de PHP lo ejecuta pepito y la función mail() es ejecutada por pepito.

Me van perfectamente los emails de varios foros que tengo instalados, a pesar de que ahora nobody no puede enviar emails.

Saludos

Salteador
25/05/2010, 18:52
Entonces es lo mismo que este activado, no funcionara igualmente.

Power
25/05/2010, 18:48
Hola,
Cita Publicado inicialmente por Salteador
Pero si pones que nobody no pueda enviar mails, los mails que se envian por ejemplo en los foros no funcionaria no?
Sí se envían, porque ahora PHP ya no lo ejecuta nobody sino el propietario de la cuenta.

Esa es una de las grandes ventajas de suPHP: seguridad.

Saludos

Salteador
25/05/2010, 18:46
Pero si pones que nobody no pueda enviar mails, los mails que se envian por ejemplo en los foros no funcionaria no?

Power
25/05/2010, 18:42
Hola,

Ya cambié mi servidor principal a suPHP.

Ejecuté el script para:
- Poner el propietario/grupo de public_html (y todos los directorios y ficheros) a cuenta:cuenta
- Cambiar los permisos de todos los directorios (desde public_html hacia abajo) a 755
- Cambiar los permisos de todos los ficheros (desde public_html hacia abajo) a 644

Puse la opción en la configuración de cPanel para que nobody no pueda enviar emails.

Y va todo como la seda.

Gracias a todos por vuestra ayuda.

Saludos

tonysanchez
18/04/2010, 13:32
El 403 es un mensaje de error de Apache, no de PHP.

Asi que tiene que buscar en el error_log de apache.

Salteador
18/04/2010, 13:26
Pero que mensaje te da el error.log? cuando pase a suphp todos los errores salian alli y puede solucionarlo sin mucha complicacion.

tonysanchez
18/04/2010, 13:20
Es asi como dice el si no hay ningun fichero html que procesar (todo son ficheros php)

Si es asi no hay problema.

Power
18/04/2010, 10:49
Hola,

Gracias Tonysanchez.
Pero no acabo de comprenderlo.

En uno de los primeros mensajes de este hilo, el colega Berilo nos indicaba un script para convertir los permisos para suPHP.
Entre otras cosas, hacía:
Código:
chown -R ${user}:${user} /home/${user}/public_html
chmod 755 /home/${user}/public_html
Y por otro lado, creo que en modo suPHP, Apache es ejecutado por el usuario de la cuenta, no por nobody.

Por eso, no acabo de entender que pueda dar errores 403.
¿Alguna aclaración?, Please.

Saludos

tonysanchez
17/04/2010, 17:52
El propietario es correcto ya que la configuracion de nobody es necesaria para el grupo, ya que el servidor web sino no puede leer ficheros de dicho directorio (en Cpanel)

LA configuracion afecta a ficheros y directorios exclusivamente trabajado spor php, por lo que los fichero pueden y deben tener por seguridad permisos mas restrictivos.

ficheros .php con un 400 vale

Si pones un /home//public_html con user:user el 403 forbiden aparece de inmediato.

Power
17/04/2010, 17:39
Hola,
Cita Publicado inicialmente por kitamarchas
Los permisos los tengo asi:

/home/user - user:user - 755
/home/user/www - user:nobody - 750
/home/user/www/directorio - user:user - 755
/home/user/www/file.php - user:user - 644

¿Cómo se supone que debo proceder?
No estoy muy avezado en este tema, pero creo que /home/user/www también debería tener como propietario:grupo user:user

Revisa tu configuración y mira si está de acuerdo con lo que dice en:
http://docs.cpanel.net/twiki/bin/vie...considerations

Saludos

tonysanchez
17/04/2010, 17:35
Aparte de eso..

  1. No puedes usar le RMEMLimit de Apache si el VPS es un OpenVZ
  2. Si el VPS llega al final de su memoria te dara muchos 500


El primer punto lo tienes en algun post del foro de proxmox.

BAsicamente es relativo a como gestiona la memoria los VPS de Proxmox (OpenVZ) y la necesidad de un reserva, que no es contada por el script de WHM que calcula el limite de memorya y CPU de Apache.

Salteador
17/04/2010, 17:28
Mira los logs de error del apache, muchas veces es problema de los flags en el .htaccess

kitamarchas
17/04/2010, 17:25
Hola, me engancho a este hilo...
Yo tengo un vps ya desde hace bastante tiempo trabajando en modo dso. He cambiado a suphp y me salen varios "Internal Server Error"

He mirado en easyapache y tengo:

Mod SuPHP - Activado
Mod FCGID - Activado
Ident - Activado
UniqueId - Activado
Usertrack - Activado
Version - Activado
Vhost Alias - Activado
Mod Security - Activado
Fastcgi - Activado
Mod FCGID - Activado
Force CGI Redirect - Activado
SafeMode - DESACTIVADO
Safe PHP CGI - DESACTIVADO

Y ESTO ACTIVADO -->
Save my profile with appropriate PHP 5 options set so that it is compatible with cpphp
This option will make the following changes to your profile prior to the build:


Los permisos los tengo asi:

/home/user - user:user - 755
/home/user/www - user:nobody - 750
/home/user/www/directorio - user:user - 755
/home/user/www/file.php - user:user - 644

¿Cómo se supone que debo proceder?
Gracias!!

tonysanchez
02/04/2010, 17:40
Ojo.

EL usuario creara el php.ini en cuantos directorios quiera personalizarlo, por lo que obvie el script para localizar nuevos php.ini instalados en el sistema...

Sino poco a poco iras teniendo php.ini sin controlar.

Tambien te digo que solo e, 0,009% de los usuarios usara el php.ini indebidamente...

Lo cual te habre puertas a otras opciones.

Saludos.

Power
02/04/2010, 17:28
Hola,

¡¡¡ Genial, Tonysanchez !!!

Estaba leyendo posibles soluciones para proteger el php.ini en:
http://docs.cpanel.net/twiki/bin/vie...considerations
http://forums.cpanel.net/f185/help-c...ni-143397.html

Pero la idea de utilizar chattr es excelente.
Utilizaré chattr +i /home/cuenta/public_html/php.ini para proteger el php.ini

Muchas gracias.

Saludos

tonysanchez
02/04/2010, 12:14
La opcion para que el usuario no pueda cambiar valores esta en el easyapache.

PEro claro eso te planteara no uno sino muchos problemas, ya que o bien pones valores para todos al gusto, o al tuyo, o tendras muchos problemas.

Yo opte por una mas simpatica, el uso de php.ini por usuario pero con el falg de no excritura con chattr

En cuanto a los otros problemas, los solventas con algun que otro script.

  1. Mania de los clientes y de los super webmaster de poner todo a 777
  2. Mania de los htaccess y los flags


Para la primera, facil, cuando migras o ponene algo, tener a mano un script para revisar el www del usuario y poner los directorios y permisos correctos.

Y los htaccess lo mismo un script que te comente los php_falgs que vienen puestos.

Para cuando los ponen con postreriroridad, y/o poenen permisos 777 porque no saben trabajar leyendo manuales, es facil, el sistema les mandara bonitos errores 500

Manualización, y que vayan aprendiendo.

NOTA:

Si puedes enseñar a los usuarios a ejecutar un script de permisos antes de hacer cosas con ftp, el mejor seguor es que los ficheros php ni siquiera deben tener 600, sino un simple 400. Asi te quitas unas cuantas posibilidades tambien de seguridad.

Power
01/04/2010, 22:35
Hola,
Cita Publicado inicialmente por sdzzds
En cpanel hay una opción para que el user no puede tocar el php.ini no recuerdo dónde (en tweaks settings creo recordar). Ojo, al cambiar a suphp debes poner el php.ini en cada directorio de cada web que tiene archivos php y quieres que le afecte ese php.ini, poniéndolo en el root no servirá para todo el sitio.

Y dos cosas principalmente:

- No escribir valores en el htacess como bien dijiste relacionados con flags del php.
- No poner permisos superiores a 644 para archivos y 755 para carpetas, ya que recibirás errores 500.
Muy útiles y claras tus recomendaciones, sdzzds. Gracias.
(No encuentro la opción para proteger el php.ini en Tweaks Settings del WHM)

Saludos

sdzzds
01/04/2010, 20:54
En cpanel hay una opción para que el user no puede tocar el php.ini no recuerdo dónde (en tweaks settings creo recordar). Ojo, al cambiar a suphp debes poner el php.ini en cada directorio de cada web que tiene archivos php y quieres que le afecte ese php.ini, poniéndolo en el root no servirá para todo el sitio.

Y dos cosas principalmente:

- No escribir valores en el htacess como bien dijiste relacionados con flags del php.
- No poner permisos superiores a 644 para archivos y 755 para carpetas, ya que recibirás errores 500.

Power
01/04/2010, 17:57
Hola,
Cita Publicado inicialmente por Arturoap
Si me aparece eso, es que lo tengo activado, no?

http://snapplr.com/snap/qmzk



Saludos.
PD: De ser así no me ha dado ningún problema activarlo...
Xasssstamente !!!

Los problemas son si se tiene en DSO funcionando y con cuentas y se quiere pasar a suPHP.
Hay que acomodar propietarios y permisos.

Saludos

Arturoap
01/04/2010, 16:21
Si me aparece eso, es que lo tengo activado, no?

http://snapplr.com/snap/qmzk



Saludos.
PD: De ser así no me ha dado ningún problema activarlo...

Power
01/04/2010, 15:49
Hola,

He corregido (no estaba completo) y adaptado a mi gusto el script para cambiar los permisos
Código:
#!/bin/bash
# Script para modificar todos los permisos para adpatarlos a suPHP
#
CUENTAS=`ls -A1 /var/cpanel/users`
for CUENTA in $CUENTAS
do
    chown -R $CUENTA.$CUENTA /home/$CUENTA/public_html
    chmod 755 /home/$CUENTA/public_html
    find /home/$CUENTA/public_html -name “*.php” -exec chmod 644 {} \;
    find /home/$CUENTA/public_html -type d -exec chmod 755 {} \;
done
Gracias Berilo.
(El original estaba en http://www.leopoldomaestro.com/scrip...php-en-cpanel/)

Y acabo de leer en http://docs.cpanel.net/twiki/bin/vie...considerations lo que comentaba Isb1009 sobre phprc_paths

Miraré bien el log de errores cuando cambie a suPHP. Gracias Salteador

Saludos y Gracias a todos por vuestra ayuda.

Salteador
01/04/2010, 14:02
Cuando puse suphp me dedique a mirar el log de errores de apache, alli vi en 95% de los errores, el resto pequeñas cosas que fui solucionando poco a poco.

Isb1009
01/04/2010, 12:32
Si no recuerdo mal, en el archivo .htaccess puedes añadir lo siguiente:
Código:
SetEnv PHPRC /directorio/donde/esta/el/php.ini/del/cliente
Es decir, sin escribir al final php.ini. Puedes ponerlo donde te plazca siempre y cuando sea propiedad del usuario en cuestión y tenga permisos de lectura.

Power
01/04/2010, 11:21
Hola,

Muchas gracias Berilo.
Muy útil el script.

Por lo que veo en tu script, el directorio /home/cuenta/public_html/ debe tener propietario:cuenta, grupo:cuenta y permisos 755
Los ficheros PHP, permisos 644 y los directorios 755.

Respecto al tema del php.ini en el directorio /home/cuenta/public_html/ ¿habría alguna forma de protegerlo para que el usuario no pudiese modificarlo?
Gracias de nuevo.

Saludos

Berilo
01/04/2010, 11:10
hace un tiempo vi por internet (no me acuerdo de donde) una forma de adaptar todas las cuentas para suphp y me lo guardé por si lo necesitaba:

Código:
for usuarios in `/bin/ls /var/cpanel/users`; do
chown -R ${user}:${user} /home/${user}/public_html
chmod 755 /home/${user}/public_html
find /home/${user}/public_html -name “*.php” -exec chmod 644 {} \;
find /home/${user}/public_html -type d -exec chmod 755 {} \;
cada usuario deberá tener su archivo completo php.ini para modificar algunas opciones de php, así que habrá que ir con cuidadito que los clientes no metan valores extraños. Supongo que se podría hacer un script que revise diariamente los archivos php.ini de los clientes en búsqueda de valores superiores a "x" y avise en caso de encontrar burradas.

Power
01/04/2010, 10:01
Hola,

Tengo cPanel en mi servidor principal, con Apache-PHP trabajando en modo DSO.

Como veo que cada día hay más problemas de seguridad, estoy pensando pasarme a modo suPHP.

Recuerdo que, hace tiempo, por error lo puse en modo suPHP y dejaron de funcionarme todas las webs hasta que volví a modo DSO.

Quería preguntaros sobre qué debería cambiar para poner el modo suPHP.

Por un lado creo que en todas las webs que tienen un .htaccess con directivas de PHP, dejan de funcionarles.
Y en su lugar hay que poner un php.ini, completo, con las directivas PHP (en formato adecuado).
¿Es así?

Por otro lado, creo que habrá que modificar permisos.
Actualmente /home/cuenta/public_html tiene propietario:cuenta, grupo:nobody y permisos 750
Los directorios que hay dentro tienen usuario:cuenta, grupo:cuenta y permisos 755
Y los ficheros usuario:cuenta, grupo:cuenta y permisos 644

Hay algunos directorios de CMS donde deben poder crearse ficheros desde web que tienen usuario:cuenta, grupo:nobody y permisos 775.
Y algunos, usuario:nobody, grupo:nobody y permisos 777.

¿Qué tendría que cambiar en ese tema de permisos para pasar a suPHP?
Gracias anticipadas por vuestra ayuda.

Saludos