Newsgroup: it.comp.os.linux.sys
Titolo: apache domini virtuali e permessi

ciao
ho un problema con i permessi di scrittura sui domini virtuali.
al momento della creazione del dominio (con relativa creazione di home
dell'utente) ho ad esempio:
/home/test
dove all'interno c'è public_html come documentroot
i permessi su questa dir e tutto il suo contenuto sono
test test per quanto riguarda i proprietari
755 per le dir
644 per i file
inoltre viene aggiunto l'utente apache (www-data) al gruppo test
il problema è che in questo modo l'utente apache non puo' scrivere/creare
file in tale directory.
Sto cercando in giro soluzioni al problema e ne ho trovate piu' di una.
Volendo evitare di dare un 777 a tutta la document root, avete qualche
consiglio / metodo da darmi?
grazie Andrea

 consiglio / metodo da darmi?
775
E comunque penso ci sia un modo per far girare l'accrocchino con i
privilegi di un utente. Mi documenterei in merito.
Enrico

 consiglio / metodo da darmi?
Benvenuto nel club. :-D
La soluzione è che....non c'è soluzione.
O meglio, c'è, ma la coperta è sempre troppo corta.
Avere la docroot scrivibile da apache significa che al primo buchetto di 
uno script php di piallano tutto senza passare dal via, dato che posson 
farci quel che vogliono.
Se il rischio è noto e accettato, e se sei in ambiente multiutente, puoi 
usare suexec/suphp per eseguire la parte dinamica con lo stesso UID 
dell'utente test, a patto di incasinarti un po' di più la vita all'atto 
dell'installazione del webserver ;-)
Quantomeno, poi, se anche lo scriptino php bucato consente il defacing, 
lo consente solamente per i file di quello specifico UID (ovvero per il 
vhost vulnerabile).
Averla non scrivibile significa "aggiustare" continuamente i permessi 
delle directory per consentire ad apache di fare solo quello che si 
ritiene necessario permettergli. Ad esempio, consentirgli di depositare 
i file in una director rendendogliela scrivibile, magari insieme con 
l'accortezza di disabilitare il motore php per quella stessa directory 
in modo che non sia possibile eseguire script uploadati ;-) Ovviamente è 
un lavoro più "continuativo" rispetto al precedente, ma consente 
sicurezze maggiori. Ed ovviamente è tanto più oneroso quanto più 
l'installazione è multiutente.
La "soluzione", quindi, dipende dallo scenario, sapendo che consentire 
da un lato significa ritrovarsi in difficoltà dall'altro e viceversa...
-- 
http://www.linkedin.com/in/skull

 privilegi di un utente. Mi documenterei in merito.
eh ,č proprio quello che mi chiedevo, ma non capisco se deve essere una
configurazione di apache (farlo girare con utenti diversi in base al
dominio, č possibile?)
oppure di sistema tramite il settaggio dei permessi / gruppi 

 oppure di sistema tramite il settaggio dei permessi / gruppi
Forse potrebbe esserti di aiuto suPHP (
www.suphp.org
).
Con suPHP gli script vengono eseguiti dall'utente per il proprio account 
mentre con il PHP funzionante come modulo essi vengono eseguiti da user 
nobody e questo comporta un rischio aggiore, con suPHP in caso di attacco 
potrebbe essere inficiata la funzionalità del solo account destinatario dell'attacco 
preservando tutti gli altri utenti del server.
Con suPHP le directory ed i file non dovranno mai essere impostate ad un 
valore maggiore rispettivamente di 755 e di 644.
Buona navigazione
-- 
INVY
www.cyberspazio.eu
Demo Content Management System

 da un lato significa ritrovarsi in difficoltà dall'altro e viceversa...
grazie della spiegazione, scelgo la strada dei permessi dati a mano quando
e dove serve :)

 consiglio / metodo da darmi?
Apache + suexec (patchato) + FastCGI + php-cgi
Utilizzando php+fastcgi, oltretutto, puoi utilizzare apache in modalità
threaded. Sulle mie macchine è altrettanto performante, se non di più, di
mod_php.
->google
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?