Producto de una serie de ataques al servidor por sitios desactualizados de Joomla/Mambo mi proveedor de hosting decidió implementar la modalidad de seguridad « PHPSuExec », o sea me restingieron los permisos a un máximo de 755. Quisiera saber si esto afectará en algo el funcionamiento de mis sitios SPIP.
Lo otro es que me piden remover cualquier instancia de « php_flag » en tus archivos .htaccess . ¿Basta con que los tenga deshabilitados desde el espcio privado cierto?
Agradecería me pudieran ayudar con estas preguntas porque esto queda lejos de lo que he aprendido de SPIP hasta ahora.
Producto de una serie de ataques al servidor por sitios desactualizados de Joomla/Mambo mi proveedor de hosting decidió implementar la modalidad de seguridad "PHPSuExec", o sea me restingieron los permisos a un máximo de 755. Quisiera saber si esto afectará en algo el funcionamiento de mis sitios SPIP.
Hola Pablo, en principio hay carpetas que requieren permisos 777 (CACHE, IMG, ecrire y ecrire/data). Esto es necesario para que SPIP pueda escribir en ellas, es decir añadir archivos o borrarlos.
Habría una solución para mantener esas carpetas con 755 y que SPIP funcione, se trata de que esas carpetas sean propiedad del usuario con el que se ejecuta el servidor web. Usando la distribución de Linux Debian y el servidor web Apache ese usuario se llama www-data y tiene el identificador de usuario (uid) 33, pero quizás tu proveedor de hosting use otra cosa. Si con el programa de FTP puedes ver las propiedades de cualquier archivo o carpeta bajo /CACHE/ es posible que puedas ver que usuario es el propietario de esos archivos y por tanto el usuario del servidor web.
No creo que puedas cambiar el propietario de las carpetas con tu programa de FTP, así que diles que necesitas que el servidor web pueda escribir en esas carpetas y ellos deberían arreglarlo.
Una vez hecho ese cambio es muy posible que ya no puedas modificar esas carpetas y su contenido mediante tu acceso FTP, pero bueno, eso no sería una dificultad insalvable.
Lo otro es que me piden remover cualquier instancia de "php_flag" en tus archivos .htaccess . ¿Basta con que los tenga deshabilitados desde el espcio privado cierto?
de esto no estoy seguro, pero me extraña que en los .htaccess de SPIP haya directivas php_flag, eso se usa para cambiar la configuración de PHP del servidor para el directorio donde esté ese .htaccess
Si tu has añadido esos php_flag quizás accedan a poner esas directivas directamente en la configuración del servidor web para tu alojamiento.
Producto de una serie de ataques al servidor por sitios desactualizados de Joomla/Mambo mi proveedor de hosting decidió implementar la modalidad de seguridad "PHPSuExec", o sea me restingieron los permisos a un máximo de 755. Quisiera saber si esto afectará en algo el funcionamiento de mis sitios SPIP.
Hola Pablo, en principio hay carpetas que requieren permisos 777 (CACHE, IMG, ecrire y ecrire/data). Esto es necesario para que SPIP pueda escribir en ellas, es decir añadir archivos o borrarlos.
Bueno, me contesto a mi mismo. He leído un poco sobre PHPSuExec y me parece que no vas a tener que cambiar nada. Según lo que he visto, en ese modo los scripts PHP pasan a ejecutarse con el usuario al que pertenecen, es decir tu usuario de FTP en vez del usuario del servidor web. Con lo que los permisos 755 deberían funcionar como los 777 en un servidor sin PHPSuExec.
Así que es posible que no tengas que cambiar nada en los permisos y todo siga funcionando bien.
Bueno, si tendrás que poner todo lo que esté ahora con 777 a 755.
Le vendredi 15 septembre 2006 à 09:12 +0200, Santi a écrit :
He leído un poco sobre PHPSuExec y me
parece que no vas a tener que cambiar nada. Según lo que he visto, en
ese modo los scripts PHP pasan a ejecutarse con el usuario al que
pertenecen, es decir tu usuario de FTP en vez del usuario del servidor
web.
Bueno, eso es si el usuario FTP es un usuario unix...
en general un hospedaje grande no le atribuye un usuario unix a cada uno
de los usuarios, sino que usa alguna manera de configuracion ProFTPd
para que login y password estén en algo como una base de datos.
Y si fuera un usuario unix (para eso, PAblo: puedes conectarte en sshh?)
puede que por ahi vengan los problemas de seguridad...