Qual è il modo migliore per gestire le autorizzazioni per i dati www dell'utente di Apache 2 in /var/www?

Soluzione 1:

Tentativo di espandere 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 gruppi esistenti

  usermod -a -G www-pub userb

  groups usera ## gruppi di visualizzazione per utente

• Cambia la proprietà di tutto ciò che si trova in /var/www in root:www-pub

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

• Modifica i permessi di tutte le cartelle a 2775

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

  Set group ID (SETGID) bit (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 penso consenta solo al proprietario di eliminare i file.

  C'è un -R 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 l'umask per i tuoi utenti in 0002

  L'umask controlla i permessi predefiniti per la creazione dei file, 0002 significa che i file avranno 664 e le directory 775. Impostando questo (modificando il umask riga in fondo a /etc/profile nel mio caso) significa che i file creati da un utente saranno scrivibili da altri utenti nel gruppo www senza bisogno di chmod loro.

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

Nota:dovrai effettuare il logout/in per rendere effettive le modifiche ai tuoi gruppi!

Soluzione 2:

Non sono del tutto sicuro di come desideri 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 modificare qualsiasi cosa in /var/www/

• Crea un nuovo gruppo (www-pub) e aggiungi gli utenti a quel gruppo.
• Cambia la proprietà di tutto ciò che si trova in /var/www in root:www-pub.
• Modifica i permessi di tutte le cartelle a 2775
• Cambia tutti i file in 0664.
• Cambia l'umask per i tuoi utenti in 0002

Ciò significa che qualsiasi nuovo file creato da uno dei tuoi utenti dovrebbe essere username:www-pub 0664 e qualsiasi directory creata sarà username:www-pub 2775. Apache otterrà l'accesso in lettura a tutto tramite il componente "altri utenti". Il bit SETGID sulle directory costringerà tutti i file creati ad essere di proprietà del gruppo che possiede la cartella. La regolazione dell'umask è necessaria per assicurarsi che il bit di scrittura sia impostato in modo che chiunque nel gruppo possa 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 evitare che rompano troppo le cose, allora andrò piano. Se l'azienda richiedesse qualcosa di più complesso, creerei qualcosa di più complesso.

Soluzione 3:

Penso che potresti trovare utili POSIX ACL (liste di controllo degli accessi). Consentono un modello di autorizzazione più granulare rispetto al modello utente:gruppo:altro. Li ho trovati più facili da tenere in mente poiché posso essere più esplicito e posso anche impostare il comportamento "predefinito" per un ramo del file system.

Ad esempio, puoi 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 basandoti su 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

Esercitazione

Soluzione 4:

Questa domanda è stata posta di nuovo e, come discusso su meta, le attuali best practice forniscono approcci migliori rispetto a quelli disponibili nel 2009, quando è stata posta. Questa risposta cerca di fornire alcune soluzioni attuali per gestire in modo sicuro gli ambienti di sviluppo web collaborativo .

Per un server web sicuro e uno sviluppo collaborativo non ci sono solo i permessi dei file:

• Avere un utente separato per ogni sito cioè non servire tutti i siti utilizzando www-data . Questo è importante, poiché al giorno d'oggi Apache raramente serve solo statico file di contenuto, ma in esecuzione dinamico siti web. Questa risposta si concentra su PHP in quanto è il linguaggio dei siti server più comune, ma gli stessi principi si applicano anche agli altri.

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

• Utilizza il protocollo di trasferimento file SSH (SFTP). Mentre l'utilizzo di FTP dovrebbe essere abbandonato per motivi di sicurezza (poiché invia sia le password che il contenuto in testo normale), il suo sostituto sicuro SFTP ha anche una funzionalità 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. Anziché fornire loro le password per questi utenti del sito (o accedere ai file del sito utilizzando i loro account utente personali come originariamente suggerito), puoi utilizzare le chiavi SSH per l'accesso.

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

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

  • Non c'è bisogno di cambiare e condividere le password ogni volta che qualcuno lascia l'azienda.

  • Puoi utilizzare password molto complesse o disabilitare del tutto l'accesso basato su password.

• Utilizza PHP-FPM . È l'approccio attuale per eseguire PHP come utente. Crea un nuovo pool per ogni utente, ovvero 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 esegue php-fpm con utente/uid e gruppo separati su Linux. Esistono tutorial come HowtoForge's Using PHP-FPM with Apache on Ubuntu 16.04 che non utilizza PHP-FPM per aumentare la sicurezza attraverso la separazione degli utenti, guidando l'utilizzo di un singolo socket FPM sul server.