Come impostare i permessi Linux per la cartella WWW?

Soluzione 1:

Dopo ulteriori ricerche, sembra che un altro modo (forse migliore) per rispondere a questa domanda sia impostare la cartella www in questo modo.

1. sudo usermod -a -G developer user1 (aggiungi ogni utente al gruppo di sviluppatori)
2. sudo chgrp -R developer /var/www/site.com/ in modo che gli sviluppatori possano lavorare lì
3. sudo chmod -R 2774 /var/www/site.com/ in modo che solo gli sviluppatori possano creare/modificare i file (other/world può leggere)
4. sudo chgrp -R www-data /var/www/site.com/uploads in modo che www-data (apache/nginx) possa creare caricamenti.

Da git viene eseguito come qualunque utente lo chiami, quindi finché l'utente è nel gruppo "sviluppatore" dovrebbe essere in grado di creare cartelle, modificare file PHP e gestire il repository git.

Nota:nel passaggio (3):'2' in 2774 significa 'impostare l'ID gruppo' per la directory. Ciò fa sì che i nuovi file e sottodirectory creati al suo interno ereditino l'ID gruppo della directory principale (invece del gruppo principale dell'utente) Riferimento:http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

Soluzione 2:

Non sono sicuro che sia "giusto", ma ecco cosa faccio sul mio server:

• /var/www contiene una cartella per ogni sito web.
• Ogni sito web ha un proprietario designato, che è impostato come proprietario di tutti i file e le cartelle nella directory del sito web.
• Tutti gli utenti che gestiscono il sito Web vengono inseriti in un gruppo per il sito Web.
• Questo gruppo è impostato come proprietario del gruppo di tutti i file e le cartelle nella directory.
• Qualsiasi file o cartella che deve essere scritta dal server web (ad es. PHP) ha il proprietario modificato in www-data, l'utente sotto cui viene eseguito apache.

Tieni presente che dovresti avere il bit di esecuzione abilitato nelle directory in modo da poter elencare i contenuti.

Soluzione 3:

Dopo aver fatto ulteriori ricerche sembra che git/svn TOOLS NON sono un problema poiché funzionano come qualsiasi utente li stia utilizzando. (Tuttavia, i demoni git/svn sono una questione diversa!) Tutto ciò che ho creato/clonato con git aveva i miei permessi e lo strumento git era elencato in /usr/bin che si adatta a questa tesi.

Autorizzazioni Git risolte.

Le autorizzazioni utente sembrano essere risolvibili aggiungendo tutti gli utenti che hanno bisogno di accedere alla directory www al www-data gruppo eseguito da apache (e nginx).

Quindi sembra che una risposta a questa domanda va così:

Di default /var/www è di proprietà di root:root e nessuno può aggiungere o modificare i file lì.

1) Cambia il proprietario del gruppo

Per prima cosa dobbiamo cambiare il gruppo di directory www in modo che sia di proprietà di "www-data" anziché del gruppo "root"

sudo chgrp -R www-data /var/www

2) Aggiungi utenti a www-data

Quindi dobbiamo aggiungere l'utente corrente (e chiunque altro) al gruppo www-data

sudo usermod -a -G www-data demousername

3) Directory CHMOD www

Cambia i permessi in modo che SOLO il proprietario (root) e tutti gli utenti nel gruppo "www-data" possano rwx (leggere/scrivere/eseguire) file e directory (nessun altro dovrebbe essere in grado di accedervi ).

sudo chmod -R 2770 /var/www

Ora tutti i file e le directory creati da qualsiasi utente che ha accesso (ad esempio nel gruppo "www-data") saranno leggibili/scrivibili da apache e quindi da php.

È corretto? Che dire dei file creati da PHP/Ruby:gli utenti di www-data possono accedervi?

Soluzione 4:

La viscosità non è l'ereditarietà dei permessi. Stickiness su una directory significa che solo il proprietario di un file, o il proprietario della directory, può rinominare o eliminare quel file nella directory, nonostante le autorizzazioni dicano diversamente. Così 1777 su /tmp/.

In Unix classico, non c'è ereditarietà dei permessi basata sul file system, solo sull'umask del processo corrente. Su *BSD, o Linux con setgid sulla directory, il campo del gruppo dei file appena creati sarà impostato sullo stesso valore della directory principale. Per qualsiasi altra cosa, devi esaminare gli ACL, con l'ACL "predefinito" sulle directory, che ti consente di avere autorizzazioni ereditate.

Dovresti iniziare definendo:* quali utenti hanno accesso al sistema* qual è il tuo modello di minaccia

Ad esempio, se stai facendo web hosting con più clienti e non vuoi che vedano i file degli altri, allora potresti usare un gruppo comune "webcusts" per tutti quegli utenti e una modalità directory di 0705. Quindi i file serviti da il processo del server web (non in "webcusts") vedrà gli altri permessi e sarà autorizzato; i clienti non possono vedere i file degli altri e gli utenti possono modificare i propri file. Tuttavia, questo significa che nel momento in cui autorizzi CGI o PHP hai per assicurarsi che i processi vengano eseguiti come utente specifico (buona pratica comunque, per più utenti su un host, per responsabilità). Altrimenti, i clienti potrebbero pasticciare con i file degli altri facendo in modo che un CGI lo faccia.

Tuttavia, se l'utente in fase di esecuzione di un sito Web è lo stesso proprietario del sito Web, si verificano problemi con l'impossibilità di proteggere il contenuto dagli abusi nel caso di una falla di sicurezza nello script. Ed è qui che vincono gli host dedicati, in modo da poter avere un utente in fase di esecuzione distinto dal proprietario del contenuto statico e non doversi preoccupare così tanto dell'interazione con altri utenti.

Soluzione 5:

Credo che il modo migliore per farlo sia utilizzare gli ACL Posix. Sono comodi da usare e offrono tutte le funzionalità di cui hai bisogno.

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs