Un usuario preguntó 👇
Tengo muchos sitios web alojados en AWS Amazon Linux Lightsail VM. Algunos de mis clientes quieren acceder a los cambios directamente en sus archivos. La mayoría de ellos solo quieren que yo me ocupe de todo. Quiero agregar un usuario que mis clientes puedan usar, que solo puedan leer / escribir en su sitio y ni siquiera ver a los demás. Actualmente estoy haciendo lo siguiente para establecer permisos en un sitio con este script:
#!/bin/bash
sudo chown -R $2.www $1
sudo chmod -R 0775 $1
find $1 -type d -exec sudo chmod 0775 {} ;
find $1 -type f -exec sudo chmod 0664 {} ;
#executed at the command line like
sh script.sh /var/www/html/somesite.com apacheEso establece el propietario del archivo en Apache y el grupo en www.
Quiero cambiar el propietario a otro usuario y dar acceso a mis clientes. Entonces creo un usuario de acuerdo con estas instrucciones: https://aws.amazon.com/premiumsupport/knowledge-center/new-user-accounts-linux-instance/ Utilizo este script para asignar los permisos a un usuario llamado ‘somesite’ como
sh script.sh /var/wwww/html/somesite.com somesite
Permisos:
drwxrwsr-x somesite www ....somesite.com
Lo que debería significar que algún sitio es el propietario y el grupo www tiene g + w, incluido Apache.
Aquí es donde realmente comienza la locura. Usando ese nuevo nombre de usuario + archivo de claves, puedo cargar medios a través de WordPress, puedo cargar archivos a través de SFTP pero no puedo instalar ningún plugin a través del administrador de WordPress. WordPress me anima a ingresar la información de FTP, generalmente si tiene los permisos eliminados.
Los permisos en un directorio de ‘plugins’ son equivalentes a ‘cargas’.
Enlace a la pregunta de flujo de existencias: https://stackoverflow.com/questions/49122080/permissions-on-multi-tenant-hosted-server-on-amazon-linux-for-wordpress
¿Alguien tenía ideas sobre cómo solucionar esto?
Este tema fue modificado hace 2 años, 11 meses por. Este tema fue modificado hace 2 años, 11 meses por. Este tema fue modificado hace 2 años, 11 meses por.
(@jayhill)
Hace 2 años, 11 meses
Agregue el usuario de algún sitio al grupo www y eso debería funcionar en teoría.
Lanzador de hilos
(@msuemnig)
Hace 2 años, 11 meses
Entonces, algún sitio tendrá acceso a todos los demás sitios de cambio, que es lo que quiero evitar. O me equivoco?
(@jdembowski)
Moderador del foro y Bruto Squad
Hace 2 años, 11 meses
Tengo muchos sitios web alojados en AWS Amazon Linux Lightsail VM.
Fresco.
Algunos de mis clientes quieren acceder a los cambios directamente en sus archivos.
Eso puede volverse pegajoso muy rápidamente.
Aquí es donde realmente comienza la locura. Usando ese nuevo nombre de usuario + palabra clave, puedo cargar medios a través de WordPress
Deseando que llegue.
pero no puedo instalar ningún plugin a través del administrador de WordPress. WordPress me anima a ingresar la información de FTP, generalmente si tiene los permisos eliminados.
Yo pienso que éste es el problema. WordPress (en realidad, el servidor web) se ejecuta como una única ID de usuario que es diferente del nuevo + nombre de usuario. Por lo tanto, el acceso a nivel de archivo regular funcionará para el nombre de usuario + clave, pero el ID de usuario del sitio web no funcionará.
Si hace que la propiedad sea demasiado permisiva, podría meterse en problemas aún más graves.
¿Existe alguna posibilidad de que el cliente pueda copiar sus archivos a un directorio de suministro en su propio directorio de inicio y luego ejecutar un script para copiar esos archivos en un directorio de WordPress?
El proceso que ejecuta el script debe ser el mismo que el del sitio web y los directorios del sitio web deben obtener la propiedad anterior y el permiso correcto. De esa manera, solo necesita revelar el directorio de suministro del cliente al sitio web a nivel de archivo / directorio.
(@ otto42)
Administración de WordPress.org
Hace 2 años, 11 meses
No estoy familiarizado con los servicios de Amazon en particular, pero estoy familiarizado con el alojamiento compartido que utiliza conjuntos de Apache. Cada usuario probablemente tiene su propia carpeta de inicio, y el public_html para cada usuario está allí, y pueden acceder a eso. Por lo tanto, cada usuario tiene su propia instalación de WordPress, más o menos un sitio individual.
Por seguridad, así es como lo hago.
En primer lugar, no desea que los archivos de WordPress sean propiedad de Apache / www. En realidad, se trata de un antibiótico para la seguridad de su sistema multiusuario. Vea, si WordPress posee la cuenta de usuario compartida de Apache, entonces eso significa que tiene acceso, posiblemente acceso de escritura a todos los archivos de WordPress en cada cuenta. Entonces podría escribir un script PHP, ejecutar WordPress en mi sitio y modificar todos los demás sitios en el mismo servidor.
Todo lo que necesita hacer es cambiar la forma en que ejecuta PHP desde Apache. Esto es común en las configuraciones de alojamiento compartido y se llama «setuser» o «suexec» o «su-php» o varias variaciones de «su».
Cómo hacerlo depende de la configuración que ya tenga, pero lo que hace es cambiar la forma en que Apache carga el proceso PHP.
Apache generalmente se ejecuta como «apache / www», por lo que cuando inicia el proceso PHP, PHP también se ejecuta como «apache / www». Todo lo que necesita hacer es ejecutar el proceso PHP como un «nombre de usuario» en su lugar. De esa manera, el proceso PHP solo tiene acceso a los archivos de ese usuario y no a ningún otro usuario del sistema.
Pero tienes varios usuarios. Entonces, ¿cómo sabe qué usuario ejecutar? Simple: utiliza PHP, que primero verifica el archivo que se está ejecutando y establece sus propios permisos, el propietario de su propio proceso, para todos los propietarios de ese archivo. Entonces, los archivos de WordPress son «nombre de usuario» y luego suPHP también se ejecuta y decide poseerlos como «nombre de usuario», y continúa siendo ese usuario por el resto de la vida del proceso.
Alternativamente, Apache tiene un edificio especial llamado «suEXEC» que inicia el proceso PHP normal como el otro usuario en cuestión. Requiere varios ajustes de configuración diferentes, y la mayoría de las compilaciones predeterminadas de Apache no lo hacen, por lo que es posible que deba crear la suya propia.
Entonces, cuando miro un sitio en aaa.com, se ejecuta como un usuario aaa. Cuando miro un sitio en bbb.com, se ejecuta como un usuario de bbb. Y el usuario de bbb no puede acceder a los archivos aaa.
Además, en una configuración de este tipo, no se produce ningún mensaje de FTP. Está con aaa, se está ejecutando como aaa, por lo que puede hacer lo que quiera con los archivos y directorios y demás.
Deberá examinar su configuración de Apache para ver cómo se está ejecutando PHP. Ya sea mod_php o FastCGI u otro, hay una configuración alternativa y probablemente un paquete que le permite ejecutar suPHP en su lugar. Esta es la respuesta real a sus problemas con el alojamiento compartido mientras mantiene la seguridad entre usuarios.
Es probable que Amazon no lo admita. Tendrá que averiguarlo usted mismo para ejecutarlo en sus sistemas. Pero puede funcionar, si puede crear su propio Apache desde la fuente o utilizar paquetes externos que Amazon no ofrece de forma predeterminada. Todos los sistemas de alojamiento compartido modernos utilizan alguna forma de este método. Si encuentra un host compartido de cualquiera de las principales, está utilizando este.
Más a menudo, y Amazon puede tener documentación sobre esto, considere usar «php-fpm»: https://wiki.apache.org/httpd/PHP-FPM haciendo lo mismo, de una manera diferente.
¿Solucionó tu problema??
0 / 0