Proprietário / grupo / permissões corretos para arquivos / pastas do site Apache 2 no Mac OS X?


114

É difícil encontrar respostas específicas para Mac para essa pergunta na web, então espero que alguém aí possa resolver isso para mim. Minhas permissões estão bagunçadas em meus sites e não tenho certeza de como corrigi-las sem apenas colocar um 777 recursivo em tudo, o que é obviamente incorreto.

Obrigado!

Respostas:


186

Esta é a maneira mais restritiva e segura que encontrei, conforme explicado aqui para o ~/my/web/root/diretório hipotético de seu conteúdo da web:

  • Para cada diretório pai levando a sua raiz web (por exemplo ~/my, ~/my/web, ~/my/web/root):
    • chmod go-rwx DIR (ninguém além do proprietário pode acessar o conteúdo)
    • chmod go+x DIR (para permitir que "usuários" incluindo _www "entrem" no diretório)
  • sudo chgrp -R _www ~/my/web/root (todo o conteúdo da web agora é do grupo _www)
  • chmod -R go-rwx ~/my/web/root (ninguém além do proprietário pode acessar o conteúdo da web)
  • chmod -R g+rx ~/my/web/root (todo o conteúdo da web agora é legível / executável / editável por _www)

Todas as outras soluções deixam arquivos abertos para outros usuários locais (que fazem parte do grupo "staff" e também obviamente estão no grupo "o" / outros). Esses usuários podem então navegar e acessar livremente as configurações do banco de dados, o código-fonte ou outros detalhes confidenciais em seus arquivos de configuração da web e scripts, se eles fizerem parte de seu conteúdo. Se isso não for um problema para você, vá com uma das soluções mais simples.


3
Eu tive que dar acesso de leitura além do sinalizador x chmod go+rx DIRno nível de diretório / Usuários / nome de usuário antes que ls parasse de lançar um erro de permissão. Imagino por que?
bhavinb

1
@mike, Todos os arquivos e diretórios ainda pertencerão a você (o usuário) e poderão ser gravados. O chgrp permite apenas que o grupo "_www" leia os arquivos.
dkamins

2
Para sistemas que esperam que os scripts do site criem suas próprias pastas e gravem seus próprios arquivos dentro do webroot (como muitos CMS fazem), tive de conceder permissões de gravação ao grupo _www. Então, a última etapa se torna chmod -R g+rwx ~/my/web/root. Alguma objeção ou uma maneira melhor de fazer isso @dkamins?
Jpsy de

1
@Jpsy Isso deve funcionar bem se seu aplicativo precisar gravar para si mesmo. Ele apresenta outros problemas de segurança em potencial se outro código também estiver sendo executado como _www (e pode alterar o código CMS de forma mal-intencionada), portanto, tome cuidado. Se você pode restringir gravável (g + w) a um subdiretório mais profundo, isso é ainda melhor.
dkamins

1
Já faz alguns anos, o tempo passa e o OS X gosta de mudar a forma como seu servidor Apache padrão funciona de tempos em tempos. Portanto, embora essa solução ainda funcione, eu recomendo fortemente a solução alternativa de criar VMs locais para testar seus aplicativos em vez de usar o OS X em si. Veja: vagrantup.com
dkamins

30

Se você realmente não gosta do Terminal, aqui está a maneira GUI de fazer dkamins dizendo a você:

1) Vá para o diretório inicial do usuário ( ludo seria meu) e, no menu Arquivo, escolha Obter informações cmdI no inspetor:

Obter seção Compartilhamento e permissões da janela de informações

2) Ao alt/optionclicar no sinal [+], adicione o grupo _www e defina sua permissão para somente leitura :

Obter informações, adicionar usuários e grupos destacados e Servidor da World Wide Web destacado

  • Portanto, considere (boa prática) não armazenar informações pessoais na raiz da pasta pessoal do usuário (e disco rígido)!
  • Você pode pular esta etapa se o grupo ** todos ** tiver permissão ** somente leitura **, mas desde o AirDrop, a pasta ** / Public / Drop Box ** é praticamente inútil ...

3) Mostre o inspetor Get Info da pasta Sites do usuário e reproduza a etapa 2 e, a partir do submenu de ação da engrenagem, escolha Aplicar aos itens incluídos ... :

Submenu de ação Obter informações Aplicar aos itens incluídos ... destacado

Voilà 3 passos e a única maneira da GUI ...


2
Não me ajudou aqui, mas é bom saber do ALT + [+]truque. Obrigado.
Tom

1
Esta é de longe a melhor maneira, alt + click mostra o usuário _www corretamente
CoolArts

Isso é verdade se você tiver o compartilhamento de arquivos de convidado ativado ou um script php malicioso instalado ... Certifique-se de que há apenas a pasta Pública e Sites que pode ser lida por todos. O passo 3 aplica-se apenas à pasta "Sites" ... Assim, normalmente outras pastas não devem ser alteradas ...
llange

Isso não deveria ser necessário. _www está no grupo todos.
DarkNeuron

É bom saber sobre este alt [+] !! Thx
Remi Grumeau

12

Eu sei que este é um post antigo, mas para qualquer um atualizando para Mountain Lion (10.8) e tendo problemas semelhantes, adicionar FollowSymLinksao seu arquivo {username} .conf (em / etc / apache2 / users /) resolveu o problema para mim. Portanto, o arquivo tem a seguinte aparência:

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

Criei um usuário "git" que não uso, e era tudo o que havia naquele diretório para editar (git.conf). Assim que atualizei o arquivo conforme descrito acima para o usuário git - o diretório que configurei foi servido corretamente pelo apache. Isso não faz sentido para mim porque meu usuário git não tem nada a ver com os diretórios criados, ou apache.
ktamlyn

9

Tópico de 2 meses, mas antes tarde do que nunca! Em 10.6, tenho minha pasta de documentos do servidor da web definida para:

owner:root
group:_www
permission:755

_www é o usuário que executa o apache no Mac OS X. Em seguida, adicionei uma ACL para permitir permissões totais ao grupo Administradores. Dessa forma, ainda posso fazer alterações com meu usuário administrador sem precisar autenticar como root. Além disso, quando quero permitir que o servidor da web grave em uma pasta, posso simplesmente usar o chmod para 775, deixando todos, exceto root: _www com apenas permissões de leitura / execução (excluindo quaisquer ACLs que apliquei)


Você não precisa definir o proprietário como 'root', mas é inofensivo. Você definitivamente não precisa dos perms o + rx que você tem - que permite que qualquer usuário local navegue e leia todo o seu conteúdo da web (incluindo possivelmente configurações com senhas de banco de dados, etc.)
dkamins

1
(veja minha resposta a esta pergunta abaixo, que é uma versão muito mais complexa desta resposta que pode ser interessante para aqueles mais paranóicos sobre segurança)
dkamins

No terminal, como vemos o que, por exemplo, o wordpress foi instalado (em relação às suas próprias permissões de arquivo), pois quero que o wordpress seja capaz de escrever seus próprios uploads de mídia ...
chegou em

5

No meu sistema 10.6:

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

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

1
Ótimo, obrigado Steve, e pelos próprios arquivos da web? / Biblioteca / WebServer / Documentos / Biblioteca / WebServer / Documentos / [arquivo] / Biblioteca / WebServer / Documentos / [diretório]
Fo.

0

O proprietário do usuário para mim é o usuário administrador e o grupo é _www e funciona com permissões definidas para 775 para dir e para arquivos 664


0

Catalina Update / Permissões de desktop

Eu me deparo com isso uma vez por ano no macOS. Eu geralmente uso o apache2 para hospedar uma pasta na minha área de trabalho.

Se você está tentando conceder acesso à desktoppasta, siga estas instruções para permitir que httpd tenha acesso a todas as pastas: https://apple.stackexchange.com/a/373139/353465


-3

Abra o terminal primeiro e depois vá para o diretório do servidor web

cd /Library/WebServer/Documents

e digite isso eo que você vai fazer é que você vai dar reade writepermissão

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

Isso certamente funcionará!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.