¿Propietario / grupo / permisos correctos para los archivos / carpetas del sitio Apache 2 en Mac OS X?


114

Es difícil encontrar respuestas específicas de Mac a esta pregunta en la web, por lo que espero que alguien pueda aclarar esta pregunta por mí. Mis permisos están estropeados en mis sitios y no estoy seguro de cómo arreglarlos sin simplemente golpear un 777 recursivo en todo lo que obviamente es incorrecto.

¡Gracias!

Respuestas:


186

Esta es la forma más restrictiva y segura que he encontrado, como se explica aquí para un ~/my/web/root/directorio hipotético para su contenido web:

  • Para cada directorio padre que lleva a su raíz web (por ejemplo ~/my, ~/my/web, ~/my/web/root):
    • chmod go-rwx DIR (nadie más que el propietario puede acceder al contenido)
    • chmod go+x DIR (para permitir que los "usuarios", incluido _www, "ingresen" al directorio)
  • sudo chgrp -R _www ~/my/web/root (todo el contenido web es ahora grupo _www)
  • chmod -R go-rwx ~/my/web/root (nadie más que el propietario puede acceder al contenido web)
  • chmod -R g+rx ~/my/web/root (todo el contenido web ahora es legible / ejecutable / editable por _www)

Todas las demás soluciones dejan archivos abiertos a otros usuarios locales (que son parte del grupo "personal" y, obviamente, están en el grupo "o" / otros). Estos usuarios pueden entonces navegar y acceder libremente a las configuraciones de la base de datos, el código fuente u otros detalles confidenciales en sus archivos de configuración web y scripts si forman parte de su contenido. Si esto no es un problema para usted, entonces vaya con una de las soluciones más simples.


3
Tuve que otorgar acceso de lectura además de la marca x con chmod go+rx DIRen el nivel del directorio / Users / username antes de que ls dejara de arrojar un error de permiso. ¿Preguntarse por qué?
bhavinb

1
@mike, todos los archivos y directorios seguirán siendo propiedad de usted (el usuario) y aún se podrán escribir. El chgrp solo permite que el grupo "_www" lea los archivos.
dkamins

2
Para los sistemas que esperan que los scripts del sitio web creen sus propias carpetas y escriban sus propios archivos dentro de webroot (como hacen muchos CMS), tuve que otorgar permisos de escritura al grupo _www. Entonces el último paso se convierte en chmod -R g+rwx ~/my/web/root. ¿Alguna objeción o una mejor manera de hacer esto @dkamins?
Jpsy

1
@Jpsy Eso debería funcionar bien si su aplicación necesita escribirse a sí misma. Introduce otros problemas de seguridad potenciales si otro código se ejecuta también como _www (y podría alterar maliciosamente el código CMS), así que tenga cuidado. Si puede restringir la escritura (g + w) a un subdirectorio más profundo, es mejor aún.
dkamins

1
Esto ya tiene algunos años, el tiempo avanza y a OS X le gusta cambiar el funcionamiento de su servidor Apache predeterminado de vez en cuando. Entonces, aunque esta solución aún funciona, en este punto recomendaría encarecidamente la solución alternativa de crear máquinas virtuales locales para probar sus aplicaciones en lugar de usar OS X en sí. Ver: vagrantup.com
dkamins

30

Si realmente no le gusta la Terminal, aquí está la forma GUI de hacer dkamins le dice:

1) Vaya al directorio de inicio de su usuario ( ludo sería mío) y en el menú Archivo elija Obtener información cmdI en el inspector:

Obtener la sección de Permisos y uso compartido de la ventana de información

2) Al alt/optionhacer clic en el signo [+], agregue el grupo _www y establezca su permiso en solo lectura :

Obtener información agregar usuarios y grupos resaltado y World Wide Web Server resaltado

  • Por lo tanto, considere (una buena práctica) no almacenar información personal en la raíz de la carpeta de inicio de su usuario (y disco duro).
  • Puede omitir este paso si el grupo ** para todos ** tiene permiso de ** solo lectura **, pero desde AirDrop, la carpeta ** / Public / Drop Box ** es casi inútil ...

3) Muestre el inspector Obtener información de la carpeta Sitios de su usuario y reproduzca el paso 2, luego, desde el submenú de acción del engranaje, elija Aplicar a los elementos adjuntos ... :

Submenú de acción Obtener información Aplicar a elementos adjuntos ... resaltado

Voilà 3 pasos y la única forma GUI ...


2
No me ayudó aquí, pero es bueno saber sobre el ALT + [+]truco. Gracias.
Tom

1
Esta es la mejor manera, con mucho, alt + clic muestra el usuario _www correctamente
CoolArts

Esto es cierto si tiene activado el uso compartido de archivos invitados o un script php malicioso instalado ... Asegúrese de que solo haya la carpeta Público y Sitios que sea "legible" para todos. El paso 3 se aplica solo a la carpeta "Sitios" ... Por lo tanto, normalmente otras carpetas no deben modificarse ...
llange

Esto no debería ser necesario. _www está en el grupo de todos.
DarkNeuron

Es bueno saber acerca de este alt [+] !! Thx
Remi Grumeau

12

Sé que esta es una publicación antigua, pero para cualquiera que se actualice a Mountain Lion (10.8) y experimente problemas similares, agregar FollowSymLinksa su archivo {username} .conf (en / etc / apache2 / users /) funcionó para mí. Entonces el archivo se ve así:

<Directory "/Users/username/Sites/">
  Options Indexes MultiViews FollowSymLinks
  AllowOverride All
  Order allow,deny
  Allow from all
</Directory>

Creé un usuario "git" que no uso, y eso era todo lo que había disponible en ese directorio para editar (git.conf). Una vez que actualicé el archivo como se describe arriba para el usuario git, el directorio que configuré fue servido correctamente por apache. Esto no tiene sentido para mí porque mi usuario git no tiene nada que ver con los directorios creados o con apache.
ktamlyn

9

Hilo de 2 meses, ¡pero más vale tarde que nunca! En 10.6, tengo la carpeta de documentos de mi servidor web configurada en:

owner:root
group:_www
permission:755

_www es el usuario que ejecuta apache en Mac OS X. Luego agregué una ACL para permitir permisos completos al grupo de administradores. De esa manera, aún puedo realizar cambios con mi usuario administrador sin tener que autenticarme como root. Además, cuando quiero permitir que el servidor web escriba en una carpeta, simplemente puedo hacer chmod a 775, dejando a todos los demás que no sean root: _www solo con permisos de lectura / ejecución (excluyendo cualquier ACL que haya aplicado)


No es necesario configurar el propietario como 'root', pero es inofensivo. Definitivamente no necesita los permisos de o + rx que tiene, que le permiten a cualquier usuario local navegar y leer todo su contenido web (incluidas posibles configuraciones con contraseñas de base de datos, etc.)
dkamins

1
(vea mi respuesta a esta pregunta a continuación, que es una versión mucho más compleja de esta respuesta que puede ser interesante para aquellos más paranoicos sobre la seguridad)
dkamins

En la terminal, ¿cómo vemos con qué, por ejemplo, se instaló wordpress (con respecto a sus propios permisos de archivo)? Quiero que wordpress pueda escribir sus propias cargas de medios ...
aterrizó el

5

En mi sistema 10.6:

vhosts folder:
 owner:root
 group:wheel
 permissions:755

vhost.conf files:
 owner:root
 group:wheel
 permissions:644

1
Genial, gracias Steve, ¿y por los archivos web? / Biblioteca / Servidor Web / Documentos / Biblioteca / Servidor Web / Documentos / [archivo] / Biblioteca / Servidor Web / Documentos / [directorio]
Fo.

0

El propietario del usuario para mí es el usuario administrador y el grupo es _www y funciona con permisos establecidos en 775 para dir y para archivos 664


0

Actualización de Catalina / Permisos de escritorio

Me encuentro con esto una vez al año en macOS. Normalmente uso apache2 para alojar una carpeta en mi escritorio.

Si está intentando dar acceso a la desktopcarpeta, debe seguir esto para permitir que httpd tenga acceso a todas las carpetas: https://apple.stackexchange.com/a/373139/353465


-3

Primero abra la terminal y luego vaya al directorio del servidor web

cd /Library/WebServer/Documents

y escriba esto y lo que va a hacer es qué le dará ready writeel permiso

sudo chmod -R o+w /Library/WebServer/Documents

¡Esto seguramente funcionará!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.