Tengo PHP ejecutándose como DSO. Como tal, mi script de instalación (que escribe en un archivo de configuración) no puede escribir nada.
¿Cómo le doy a Apache (usuario: nadie) la capacidad de escribir en el archivo?
Respuesta1
Sólo haría esto en un servidor de desarrollo en un entorno seguro. Muchas aplicaciones PHP generarán el archivo en la pantalla para que pueda copiarse de forma segura en el directorio de configuración.
La forma rápida (e insegura) de hacer esto es ejecutar chmod 777 .desde el directorio donde debe ir el archivo. Antes de hacer esto, ejecute ls -ld .para obtener los permisos a los que los volverá a configurar. En algunos casos, el directorio requerido no existirá, por lo que deberá crearlo primero. Inmediatamente después de escribir el archivo de configuración, restablezca el directorio a sus permisos originales. Es probable chmod 755 .que se ejecute el comando correcto chmod 750 .desde el directorio. Verifique con el comando ls.
Cambie los permisos en el archivo de configuración para que Apache ya no pueda escribir en él ( chmod o-w configfile). Las aplicaciones suelen venir con archivos de configuración de ejemplo. Colocar uno de estos en el directorio de configuración y editarlo puede ser un mejor enfoque. Esto requiere que aprenda y comprenda las opciones de configuración. Es posible que pueda utilizar el script de configuración en línea para ayudarle en sus ediciones.
Respuesta2
Puede escribir sus archivos de configuración en un directorio temporal como /tmp/config/. Luego, puede ejecutar un script de shell para copiar los archivos de configuración a /tmp/config/la ubicación deseada.
Para otorgar los permisos necesarios, puede agregar el usuario nobodyal archivo sudoers. La entrada debería verse así:
nobody ALL=NOPASSWD: /path/to/your_script.sh
El script de shell (no olvide agregar permiso de ejecución).
cp -r /tmp/config/* /desired/path/to/config
En PHP, necesitas un pequeño fragmento de código como:
<?php
$output = shell_exec('sudo /path/to/your_script.sh');
echo "$output";
?>
Respuesta3
En un entorno compartido todo se complica un poco cuando se trata de cuestiones de seguridad. Al cambiar la propiedad del archivo a 'nadie', le otorga a Apache acceso de escritura a ese archivo pero, si el módulo PHP no tiene configuraciones para restringir cada virtualhost a su propio directorio, también le daría a otros acceso a él. Comprueba cómo está configurado en tu entorno.
Apache generalmente se ejecuta como usuario 'nadie' y grupo 'nadie', por lo que también puedes jugar con permisos de grupo. Cambie el grupo del archivo a "nadie" y establezca el permiso en 664.
Si no puede cambiar el propietario o grupo del archivo, FTP normalmente le permite cambiar los permisos. Suponiendo que Apache no sea uno de los usuarios/grupos propietarios de ese archivo, tendría que configurarlo en 777, lo cual es muy inseguro, pero todo depende del tipo de entorno en el que se encuentre. Quizás pueda configurarlo temporalmente , instale su aplicación y cámbiela nuevamente a 644 o 444 (solo lectura).
Respuesta4
Este es el problema típico al ejecutar PHP como DSO con cPanel, pero también se aplica a otras configuraciones.
Al ejecutar este método, los procesos PHP son manejados por el usuario que ejecuta httpd. En la mayoría de los casos, este usuario es el usuario "nadie". Esto significa que cuando PHP interactúa con archivos en el sistema de archivos, el usuario "nadie" debe poder acceder a ellos. Esto crea problemas de permisos ya que su usuario normal basado en cPanel no tendrá acceso a los archivos RW (lectura/escritura) que son propiedad del usuario "nadie" sin los cambios de permisos correctos. La mayoría de las aplicaciones/scripts web PHP necesitan escribir en archivos y directorios y, si son propiedad del usuario de cPanel, sin cambiar los permisos de los archivos/directorios a 777, causará problemas y, en algunos casos, dañará su(s) sitio(s) web. .
Entonces, en este caso, solo puede administrar los permisos manualmente, configurándolos en 777.
Al ejecutar este método PHP, tendrá que administrar manualmente los permisos por usuario para garantizar que sus aplicaciones/scripts PHP puedan leer y escribir en los archivos y directorios que necesita para funcionar.
O, mejor aún, si puedes pasar a Mod_SuPHP y no tienes problemas de rendimiento (ya que DSO es mucho más rápido), podrás ejecutar PHP como el usuario que ejecuta cPanel.
Si pasamos por alto los problemas de permisos que uno puede encontrar al ejecutar PHP a través de DSO, existen algunos beneficios en comparación con SuPHP. La primera es la velocidad. Mod_PHP es más rápido que Mod_SuPHP. Esto se debe principalmente al hecho de que cada solicitud procesada por Mod_SuPHP se empaqueta para ejecutarse como el usuario propietario de los archivos. Es posible que esto no sea muy notorio en sitios con poco tráfico, pero en sitios con mayor tráfico, puede acumularse bastante rápido. El segundo es la funcionalidad completa con adiciones de almacenamiento en caché de código de opción PHP como eAcclerator, APC y Xcache. Para obtener el beneficio completo de un caché de código de opción PHP, necesita un usuario compartido que se use al almacenar en caché el código de bytes PHP compilado y ejecutar PHP a través de un DSO ejecuta PHP ya que el usuario "nadie" satisface esta necesidad. Puede saber si su servidor está configurado para ejecutar PHP a través de un DSO yendo a WHM y buscando en Principal >> Configuración de servicio >> Configuración de Apache. >> Configuración PHP y SuExec
Aquí puedes encontrar más detalles:
https://helpdesk.wiredtree.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1663