Proprietario / gruppo / permessi corretti per file / cartelle del sito Apache 2 in Mac OS X?

114

È difficile trovare risposte specifiche per Mac a questa domanda sul Web, quindi spero che qualcuno là fuori possa metterlo a riposo per me? Le mie autorizzazioni sono sbagliate sui miei siti e non sono sicuro di come risolverle senza semplicemente sbattere un 777 ricorsivo su tutto ciò che è ovviamente errato.

Grazie!

— Fo.
fonte

186

Questo è il modo più restrittivo e sicuro che ho trovato, come spiegato qui per una ~/my/web/root/directory ipotetica per i tuoi contenuti web:

Per ogni directory principale che conduce al vostro spazio web (ad esempio ~/my, ~/my/web, ~/my/web/root):
- chmod go-rwx DIR (nessun altro oltre al proprietario può accedere ai contenuti)
- chmod go+x DIR (per consentire agli "utenti" incluso _www di "entrare" nella directory)
sudo chgrp -R _www ~/my/web/root (tutto il contenuto web è ora di gruppo _www)
chmod -R go-rwx ~/my/web/root (nessun altro oltre al proprietario può accedere ai contenuti web)
chmod -R g+rx ~/my/web/root (tutto il contenuto web è ora leggibile / eseguibile / inseribile da _www)

Tutte le altre soluzioni lasciano i file aperti ad altri utenti locali (che fanno parte del gruppo "staff" oltre ad essere ovviamente nel gruppo "o" / altri). Questi utenti possono quindi esplorare e accedere liberamente a configurazioni DB, codice sorgente o altri dettagli sensibili nei file di configurazione Web e negli script, se questi fanno parte del contenuto. Se questo non è un problema per te, allora scegli con tutti i mezzi una delle soluzioni più semplici.

— dkamins
fonte

3

Ho dovuto concedere l'accesso in lettura oltre al flag x con chmod go+rx DIRil livello di directory / Users / nomeutente prima che ls smettesse di generare un errore di autorizzazione. Mi chiedo perché?

— bhavinb

1

@mike, Tutti i file e le directory saranno ancora di tua proprietà (l'utente) e saranno ancora scrivibili. Il chgrp consente solo al gruppo "_www" di leggere i file.

— dkamins il

2

Per i sistemi che si aspettano che gli script del sito web creino le proprie cartelle e scrivano i propri file all'interno di webroot (come fanno molti CMS), ho dovuto concedere i permessi di scrittura al gruppo _www. Quindi l'ultimo passaggio diventa chmod -R g+rwx ~/my/web/root. Qualche obiezione o un modo migliore per farlo @dkamins?

— Jpsy

1

@ Jpsy Dovrebbe funzionare bene se la tua app deve scrivere su se stessa. Introduce altri potenziali problemi di sicurezza se altro codice è in esecuzione anche come _www (e potrebbe alterare in modo dannoso il codice CMS), quindi fai solo attenzione. Se puoi limitare scrivibile (g + w) a una sottodirectory più profonda, è ancora meglio.

— dkamins

1

Questo ha pochi anni ormai, il tempo avanza e OS X ama cambiare il modo in cui funziona il suo server Apache predefinito di volta in volta. Quindi, sebbene questa soluzione funzioni ancora, a questo punto consiglio vivamente la soluzione alternativa di creare VM locali per testare le tue app invece di utilizzare OS X stesso. Vedi: vagrantup.com

— dkamins

30

Se davvero non ti piace il terminale, ecco il modo in cui la GUI per fare dkamins ti dice:

1) Vai alla directory home dell'utente ( ludo sarebbe il mio) e dal menu File scegli Ottieni informazioni cmdI nell'ispettore:

Ottieni la sezione Condivisione e autorizzazioni della finestra Informazioni

2) Facendo alt/optionclic sul segno [+] aggiungi il gruppo _www e imposta la sua autorizzazione in sola lettura :

Ottieni informazioni aggiungi utenti e gruppi evidenziati e World Wide Web Server evidenziato

Quindi considera (buona pratica) non memorizzare le informazioni personali nella radice della cartella home dell'utente (e del disco rigido)!
Puoi saltare questo passaggio se il gruppo ** tutti ** ha il permesso di ** sola lettura ** ma poiché AirDrop la cartella ** / Public / Drop Box ** è per lo più inutile ...

3) Mostra l' ispettore Ottieni informazioni della cartella Siti dell'utente e riproduci il passaggio 2, quindi dal sottomenu dell'azione dell'ingranaggio scegli Applica agli elementi inclusi ... :

Sottomenu dell'azione Ottieni informazioni Applica agli elementi inclusi ... evidenziato

Voilà 3 passaggi e la GUI solo modo ...

— llange
fonte

2

Non mi ha aiutato qui, ma è bene sapere del ALT + [+]trucco. Grazie.

— Tom

1

Questo è di gran lunga il modo migliore, alt + clic mostra l'utente _www corretto

— CoolArts

Questo è vero se hai attivato la condivisione di file guest o è installato uno script php dannoso ... Assicurati che ci sia solo la cartella Public e Sites "leggibile" da tutti. Il passaggio 3 si applica solo alla cartella "Siti" ... Quindi normalmente le altre cartelle non dovrebbero essere modificate ...

— llange

Questo non dovrebbe essere necessario. _www è nel gruppo tutti.

— DarkNeuron

Buono a sapersi su questo alt [+] !! Thx

— Remi Grumeau

12

So che questo è un vecchio post, ma per chiunque aggiorni a Mountain Lion (10.8) e riscontri problemi simili, l'aggiunta FollowSymLinksal tuo file {username} .conf (in / etc / apache2 / users /) ha fatto il trucco per me. Quindi il file ha questo aspetto:

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

— mjswensen
fonte

Ho creato un utente "git" che non uso, ed era tutto quello che c'era da modificare in quella directory (git.conf). Una volta aggiornato il file come descritto sopra per l'utente git, la directory che ho impostato è stata servita correttamente da apache. Questo non ha senso per me perché il mio utente git non ha nulla a che fare con le directory create, o apache.

— ktamlyn

9

Discussione di 2 mesi, ma meglio tardi che mai! Nella versione 10.6, la cartella dei documenti del server Web è impostata su:

owner:root
group:_www
permission:755

_www è l'utente che esegue Apache su Mac OS X. Ho quindi aggiunto un ACL per consentire autorizzazioni complete al gruppo Administrators. In questo modo, posso comunque apportare modifiche con il mio utente amministratore senza dover autenticarmi come root. Inoltre, quando voglio consentire al webserver di scrivere in una cartella, posso semplicemente fare il chmod a 775, lasciando tutti tranne root: _www con i soli permessi di lettura / esecuzione (esclusi eventuali ACL che ho applicato)

— Tim Mackey
fonte

Non è necessario impostare il proprietario su "root", ma è innocuo. Sicuramente non hai bisogno dei perm o + rx che hai - che consente a qualsiasi utente locale di navigare e leggere tutti i tuoi contenuti web (comprese possibilmente configurazioni con password DB, ecc.)

— dkamins

1

(vedi la mia risposta a questa domanda di seguito che è una versione molto più complessa di questa risposta che potrebbe essere interessante per i più paranoici sulla sicurezza)

— dkamins

Nel terminale come vediamo con cosa, ad esempio, è stato installato wordpress (per quanto riguarda i permessi dei file) poiché voglio che wordpress sia in grado di scrivere i propri caricamenti multimediali ...

— atterrato il

5

Sul mio sistema 10.6:

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

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

— Steve Graham
fonte

1

Ottimo, grazie Steve, e per i file web stessi? / Library / WebServer / Documents / Library / WebServer / Documents / [file] / Library / WebServer / Documents / [directory]

— Fo.

0

Il proprietario dell'utente per me è l'utente amministratore e il gruppo è _www e funziona con i permessi impostati su 775 per dir e per i file 664

— michalzuber
fonte

0

Catalina Update / Autorizzazioni desktop

Mi imbatto in questo una volta all'anno su macOS. Di solito utilizzo apache2 per ospitare una cartella sul desktop.

Se stai tentando di dare accesso alla desktopcartella, devi seguire questo per consentire a httpd di avere accesso a tutte le cartelle: https://apple.stackexchange.com/a/373139/353465

— Sean_Codes
fonte

-3

Apri prima il terminale e poi vai alla directory del server web

cd /Library/WebServer/Documents

e poi digita questo e quello che farai è dare reade il writepermesso

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

Questo funzionerà sicuramente!

— Sidharth kaushik
fonte