Qual è il modo migliore di gestire le autorizzazioni per i dati www degli utenti di Apache 2 in / var / www?

Qualcuno ha una buona soluzione per la gestione dei file /var/www? Stiamo eseguendo host virtuali basati sul nome e l'utente di Apache 2 è www-data .

Abbiamo due utenti regolari e root. Quindi, quando si scherza con i file /var/www, anziché dover ...

chown -R www-data:www-data

... tutto il tempo, qual è un buon modo di gestirlo?

Domanda supplementare: in che misura si procurano le autorizzazioni?

Questo è sempre stato un problema negli ambienti di sviluppo collaborativo.

Tentativo di ampliare la risposta di @ Zoredache , dato che ci provo anch'io:

• Crea un nuovo gruppo (www-pub) e aggiungi gli utenti a quel gruppo

  groupadd www-pub

  usermod -a -G www-pub usera ## deve usare -a per aggiungere a gruppi esistenti

  usermod -a -G www-pub userb

  groups usera ## gruppi di visualizzazione per l'utente

• Cambia la proprietà di tutto in / var / www in root: www-pub

  chown -R root:www-pub /var/www ## -R per ricorsivo

• Modificare le autorizzazioni di tutte le cartelle su 2775

  chmod 2775 /var/www ## 2 = imposta ID gruppo, 7 = rwx per il proprietario (root), 7 = rwx per il gruppo (www-pub), 5 = rx per il mondo (incluso apache www-data user)

  Set bit ID gruppo ( SETGID ) (2) fa sì che il gruppo (www-pub) venga copiato in tutti i nuovi file / cartelle creati in quella cartella. Altre opzioni sono SETUID (4) per copiare l'id utente e STICKY (1) che a mio avviso consente solo al proprietario di eliminare i file.

  C'è -Run'opzione ricorsiva, ma che non discrimina tra file e cartelle, quindi devi usare find , in questo modo:

  find /var/www -type d -exec chmod 2775 {} +

• Cambia tutti i file in 0664

  find /var/www -type f -exec chmod 0664 {} +

• Cambia umask per i tuoi utenti in 0002

  Umask controlla i permessi di creazione dei file predefiniti, 0002 significa che i file avranno 664 e le directory 775. Impostando questo (modificando la umaskriga in fondo /etc/profileal mio caso) significa che i file creati da un utente saranno scrivibili da altri utenti nel www- gruppo senza bisogno di chmodloro.

Prova tutto ciò creando un file e una directory e verificando il proprietario, il gruppo e le autorizzazioni con ls -l.

Nota: è necessario disconnettersi / accedere per rendere effettive le modifiche ai gruppi!

Non sono del tutto sicuro di come si desidera configurare le autorizzazioni, ma questo potrebbe darti un punto di partenza. Probabilmente ci sono modi migliori. Presumo che tu voglia che entrambi gli utenti siano in grado di cambiare qualsiasi cosa in / var / www /

• Crea un nuovo gruppo (www-pub) e aggiungi gli utenti a quel gruppo.
• Cambia la proprietà di tutto in / var / www in root: www-pub.
• Modificare le autorizzazioni di tutte le cartelle su 2775
• Cambia tutti i file in 0664.
• Cambia umask per i tuoi utenti in 0002

Ciò significa che qualsiasi nuovo file creato da uno dei tuoi utenti dovrebbe essere un nome utente: www-pub 0664 e qualsiasi directory che verrà creata sarà un nome utente: www-pub 2775. Apache avrà accesso in lettura a tutto tramite il componente "altri utenti". Il bit SETGID sulle directory forzerà la proprietà di tutti i file creati dal gruppo proprietario della cartella. È necessario regolare umask per assicurarsi che il bit di scrittura sia impostato in modo che chiunque nel gruppo sia in grado di modificare i file.

Per quanto riguarda quanto hardcore vado sui permessi. Dipende completamente dal sito / server. Se ci sono solo 1-2 editor e ho solo bisogno di impedire loro di rompere le cose troppo male, allora andrò facile. Se l'azienda avesse richiesto qualcosa di più complesso, avrei creato qualcosa di più complesso.

Penso che potresti trovare POSIX ACL (liste di controllo degli accessi) utili. Consentono un modello di autorizzazione più preciso rispetto all'utente: gruppo: altro modello. Ho scoperto che sono più facili da tenere dritti nella mia testa poiché posso essere più esplicito e anche impostare il comportamento "predefinito" per un ramo del file system.

Ad esempio, è possibile specificare esplicitamente le autorizzazioni di ciascun utente:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Oppure puoi farlo in base a un gruppo condiviso:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

E forse vuoi mantenere il tuo utente Apache in sola lettura

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Pagine man:

• setfacl
• getfacl

lezione

Questa domanda è stata posta di nuovo e, come discusso sulla meta, le migliori pratiche attuali forniscono approcci migliori di quelli disponibili nel 2009, quando questo è stato posto. Questa risposta cerca di fornire alcune soluzioni attuali per la gestione sicura degli ambienti collaborativi di sviluppo Web .

Per un server Web sicuro e uno sviluppo collaborativo ci sono molto di più delle semplici autorizzazioni per i file:

• Avere un utente separato per ogni sito, cioè non servire tutti i siti che utilizzano www-data. Questo è importante, poiché oggigiorno Apache raramente serve solo file di contenuto statico , ma esegue siti Web dinamici . Questa risposta si concentra su PHP in quanto è il linguaggio del sito server più comune , ma gli stessi principi si applicano anche agli altri.

  Se si riscontra un problema di sicurezza in un singolo sito, può diffondersi su tutti i siti in esecuzione come lo stesso utente. Un utente malintenzionato può visualizzare tutto ciò che l'utente vede, comprese le informazioni di accesso al database e modificare ogni sito a cui l'utente dispone delle autorizzazioni di scrittura.

• Usa il protocollo SSTP ( Transfer File Protocol ). Mentre l'utilizzo dell'FTP deve essere abbandonato per motivi di sicurezza (in quanto invia sia le password che il contenuto in testo semplice), il suo sostituto sicuro SFTP ha anche una funzione che è una soluzione perfetta per lo sviluppo web collaborativo.

  Dopo aver isolato i siti e un utente per sito, devi dare accesso ai tuoi sviluppatori web, di cosa tratta questa domanda. Invece di fornire loro le password per questi utenti del sito - o accedere ai file del sito utilizzando i loro account utente personali come suggerito in origine - è possibile utilizzare le chiavi SSH per l'accesso.

  Ogni sviluppatore può generare la coppia di chiavi e mantenere segreta la chiave privata. Quindi, la chiave pubblica viene aggiunta al ~/.ssh/authorized_keysfile per ogni account utente del sito Web su cui sta lavorando lo sviluppatore. Questo ha molti vantaggi per la gestione di password e accessi:

  • Ogni sviluppatore può avere accesso a qualsiasi numero di siti Web senza l'onere di ricordare o archiviare tutte le password coinvolte nell'accordo utente per sito.

  • Non è necessario modificare e condividere le password ogni volta che qualcuno lascia l'azienda.

  • È possibile utilizzare password molto potenti o disabilitare del tutto l'accesso basato su password.

• Usa PHP-FPM . È l'approccio attuale per l'esecuzione di PHP come utente. Crea un nuovo pool per ogni utente, ad esempio un pool per ogni sito. Questo è il migliore sia per la sicurezza che per le prestazioni, in quanto puoi anche specificare quante risorse può consumare un singolo sito.

  Vedi ad es. NeverEndingSecurity's Run php-fpm con user / uid separato e gruppo su linux . Esistono tutorial come HowtoForge's Using PHP-FPM con Apache su Ubuntu 16.04 che non usa PHP-FPM per aumentare la sicurezza attraverso la separazione degli utenti, guidando a usare un singolo socket FPM sul server.