en centos 7, he creado un sitio web de WordPress con propiedad del directorio raíznombre del sitio web: grupo de sitios weby permisos de directorio755, permisos de archivos644establecido por defecto
cuando el desarrollador inició sesión en el panel de WordPress e intentó cargar algo en los medios o instalar complementos, el wp dice que no hay permiso de escritura,
luego tuve que otorgar permisos a g+w para el directorio raíz de wp, luego pudo instalar el complemento o cargar medios.
después de cargar los medios, el permiso del complemento/medios cargado cambia aapache: apachedenombre del sitio web: grupo de sitios web
¿como evitar?
- Le doy permisos g+x al directorio raíz de wp para permitir que el desarrollador instale complementos/cargue medios
- y la propiedad de cualquier carga desde wp dashboar no debería cambiar a apache:apache
lo que intenté
Actualmente no encontré ninguna alternativa para detener esto, cada vez tuve que otorgar permisos a g+w y revertirlos después del trabajo del desarrollador.
Respuesta1
El servidor web (o el proceso PHP, según su configuración) necesita acceso de escritura al directorio. La única forma factible es ejecutar dicho proceso como usuario websitename.
Principalmente, otra opción sería otorgarle al usuario apachepermisos de escritura a través de ACL o agregándolo al websitegroupgrupo, pero eso también daría como resultado que los archivos cargados sean propiedad de apache. Si desea que todos los archivos y carpetas sean propiedad suya, websitenamedebe ejecutar el servidor web como ese usuario.
Respuesta2
Su descripción de cómo se aprovisiona esto no es útil. Empecemos desde cero.
Usuarios:
- Apache: el uid que ejecuta su tiempo de ejecución de PHP
- dev1, dev2, dev2 - desarrolladores
- copia de seguridad: para crear copias de seguridad del sitio
- soporte[n] - para investigar problemas
Debido a la forma en que está diseñado Wordpress, es muy difícil de operar a menos que "apache" tenga acceso completo de lectura/escritura al sitio.
Si toda la gestión se realiza a través de la interfaz de usuario web, los desarrolladores necesitancualquieracceso a los archivos en la raíz del documento. Sin embargo, he visto sitios donde los desarrolladores utilizan habitualmente el acceso CLI a archivos actualizados. Entonces supongamos que necesitan acceso de lectura/escritura.
Los uids de respaldo necesitan acceso de solo lectura a los archivos.
El soporte necesita acceso de solo lectura a los archivos.
Eso simplemente deja al usuario del sitio. Esta es tu construcción. A falta de información adicional sobre cómo se utiliza esto, parece completamente redundante.
Entonces las únicas clases de acceso son lectura+escritura y sólo lectura. Pero sólo por diversión, diremos que hay una clase adicional sin acceso y llamaremos a este usuario "alienígena".
La propiedad del usuario siempre está determinada por el uid que crea un archivo y tiene un valor único por usuario. Entonces no podemos usar eso como un mecanismo para permitir el acceso.
Sin embargo, los usuarios pueden pertenecer a varios grupos y cada grupo puede tener varios usuarios. Entonces podemos asociar el privilegio de lectura-escritura con un grupo específico. Llámelo actualización web.
Eso deja acceso de solo lectura (copia de seguridad y soporte), que se puede proporcionar a través de los "otros" bits de permiso.
Pero ¿cómo entonces se excluye lo "extraterrestre"? Al colocar el sitio en un directorio al que los extranjeros no tienen acceso, eso significa que necesitamos otro grupo que identifique a las personas que tienenalgunoacceso. Llame a este acceso web.
Entonces la membresía del grupo:
- actualización web: apache, dev1, dev2...devn
- acceso web: apache, dev1, dev2...devn, copia de seguridad, soporte[n]
luego tenemos los directorios, permisos y propiedad:
drwxr-x--- root:webaccess /var/www/SITENAME
drwxrwxr-x ????:webupdate /var/www/SITENAME/html (document root)
Todo muy bien, pero cuando alguien en "webupdate" crea un nuevo archivo o directorio en la raíz del documento, la propiedad del grupo será su grupo PREDETERMINADO, no webupdate. Puedes cambiar este comportamiento con el bit setgid en los directorios:
drwxrwSr-x ????:webupdate /var/www/SITENAME/html
La última parte del rompecabezas es garantizar que la umask esté configurada en 00x para los miembros de webupdate para que los nuevos archivos y directorios adquieran los permisos correctos). No olvide configurar esto en su sshd_config para el servidor sftp así como para shells interactivos.
Por lo tanto, una vez que tenga los grupos en su lugar, puede ejecutar:
chown -R apache:webupdate /var/www/SITENAME/html
chmod -r g+s /var/www/SITENAME/html
Y eso es todo: nunca más deberías tener que arreglar los permisos.