Tophost

[Tophost]

Qual'è la nostra 'policy' in merito l'uso del CHMOD? Come si devono comportare gli utenti per cambiare il permesso di alcuni file e cartelle? Queste domande sono tra le più 'gettonate' tra i nostri clienti, sicuramente perchè i nostri spazi sono stati pensati e configurati in modo particolare.

La nostra configurazione è stata pensata con un occhio di riguardo alla sicurezza pur cercando di salvaguardare la libertà d'azione del cliente, anche se alla fine per un corretto operare nei nostri spazi bisogna tener conto di alcune norme ben precise.


E' possibile modificare i CHMOD nei nostri spazi?
Si è possibile! Per i file perl/cgi che vanno eseguiti e che risiedono nella cartella cgi-bin, il settaggio consigliato è 750. Se per caso si utilizza un settaggio diverso, come ad esempio il 777, o il 775 per un file, oppure si esegue un settaggio anche a 750 per una cartella scatta un meccanismo di protezione che blocca l'esecuzione dei file con conseguente errore.

E' possibile impostare i permessi di file e cartelle in qualsiasi parte del sito, prestando comunque attenzione che il settaggio a 777 fa scattare il meccanismo di protezione.

In questo ultimo caso la soluzione consiste nel cliccare su "Ripristino spazio web" dal pannello di controllo e poi prestare attenzione a come si impostano i permessi ai file.


Perchè non è consigliato settare a CHMOD 777 e fare questo genera un errore?
Perchè non serve! Solitamente gli spazi web hanno l'interprete PHP che gira come modulo di Apache e quindi come utente ad esempio "WWW", mentre i file che si caricano con il client FTP appartengono ad un utente diverso che chiameremo "FTP". Gli script PHP, dell'utente WWW, per poter utilizzare/manipolare i file che appartengono all'utente FTP hanno bisogno del permesso e qui entra in gioco il famoso CHMOD, comando che permette di cambiare i permessi ai file.
Nei nostri spazi è tutto più semplice perchè PHP ed FTP appartengono allo stesso utente "FTP" e quindi PHP non deve chiedere nessun permesso per andare a manipolare/utilizzare i file che sono stati creati con FTP.


Come mai se dite che è così semplice e tutto dovrebbe andare senza toccare nulla il mio script non funziona?
Il problema è che alcuni script sono programmati in modo 'ottuso' e non vediamo il motivo di abbassare le nostre difese per errori dovuti ad altri. Che significa questo? Purtroppo esistono alcuni script che non verificano se possono scrivere in un determinato file o meno, bensì controllano solo il CHMOD attuale di un determinato file e a priori se non trovano il valore desiderato "pensano" che tale file non sia scrivibile, quando invece a tutti effetti lo è. Quando viene effettuato un settaggio a 777 entra in funzione un controllo di sicurezza che blocca file e cartelle con questo settaggio. A questo punto bisogna cliccare su "Ripristino spazio web" dal pannello di controllo.

Ma è veramente più sicuro questo settaggio?
Si e per diversi motivi qui elencati:

• questo settaggio non permette il "cross-hacking", ossia se un utente fa girare nel proprio sito del software bacato ed un hacker riesce a bucare il sito potrà limitarsi a fare danni solamente in quel sito visto che ogni sito web ha un PHP con i permessi personalizzati;
• settare una qualsiasi cartella o file a CHMOD 777 significa consegnare le chiavi dell'intero server in mano agli hacker e questo non possiamo permetterlo.

Posso settare un file a 444 o a "sola lettura" senza incorrere in blocchi?
Certamente! Le configurazioni più restrittive rendono ancora più sicuri i file e le cartelle presenti nello spazio web.

[WH.it]

Perchè non è consigliato settare a CHMOD 777 e fare questo genera un errore?
Perchè non serve! Solitamente gli spazi web hanno l'interprete PHP che gira come modulo di Apache e quindi come utente ad esempio "WWW", mentre i file che si caricano con il client FTP appartengono ad un utente diverso che chiameremo "FTP". Gli script PHP, dell'utente WWW, per poter utilizzare/manipolare i file che appartengono all'utente FTP hanno bisogno del permesso e qui entra in gioco il famoso CHMOD, comando che permette di cambiare i permessi ai file.
Nei nostri spazi è tutto più semplice perchè PHP ed FTP appartengono allo stesso utente "FTP" e quindi PHP non deve chiedere nessun permesso per andare a manipolare/utilizzare i file che sono stati creati con FTP.
 

Volevo sapere: come si può impostare questo tipo di opzione su un server? cosa bisogna fare? comporta un carico maggiore per il server, un appesantimento dello stesso o qualche possibile errore di incompatibilità o altro? lo chiedo perché un mio amico ha preso un hosting che carica php appunto come un altro utente, e io non voglio settare i permessi a 777, dunque pensavo di suggerire questa soluzione ai tecnici. Potresti dirmi cosa sarebbe necessario fare? Grazie

[Tophost]

Nel nostro caso abbiamo installato PHP come CGI e non come modulo apache. In questo modo PHP puo' venir fatto girare con gli stessi permessi del client FTP.

[Volverine]

Salve,
basta configurare il server web per funzionare il modalità suexec.
http://httpd.apache.org/docs/2.0/suexec.html
http://httpd.apache.org/docs/1.3/suexec.html

a presto  

[Tophost]

Fatta la prova......funziona perfettamente coi permessi a 640

A questo punto mi chiedo: ma perchè sottolineare con tanta solerzia i permessi obbligatori a 777 ?? Mah.

Molto semplice: perchè nella maggior parte degli hoster l'utente e il gruppo che eseguono il processo Web sono differenti dall'utente e dal gruppo che eseguono il processo FTP e facendo l'upload dei file via FTP questi avrebbero come proprietà l'utente e il gruppo di quest'ultimo. Quindi in questa situazione il 777 garantirebbe la scrittura al processo Web. Su Tophost invece l'utente e il gruppo del processo Web sono gli stessi del processo FTP rendendo quindi inutili i permessi 777, in quando anche con 600 il processo Web riuscirebbe a scrivere (possedendo anche lui i file in questione).

PS: a mio parere la scelta di Tophost è la migliore in termini di sicurezza e di utilizzo, unica piccola pecca è che così il PHP deve essere eseguito come processo esterno e non come mod_php con un piccolo degrado delle prestazioni che riduce il numero di domini ospitabili sulla macchina.

Ottimo spiegazione che amplia la descrizione del funzionamento chmod nei nostri spazi. Grazie.

La riportiamo in questo thread a beneficio di tutti.

[Aily]

vorrei una delucidazione in merito, ho un mkportal e ipb 1.3 su tophost all'inizio quando l'hoinstallati ho settato i permessi a 777 come veniva chiesto, non ho mai riscontrato questo blocco delle cartelle, poi una volta installato ho controllato di nuovo i permessi ed ora sono a 740 e il forum a 755, cosa vuol dire? e' un settaggio sicuro, arriva in automatico?

[pino82]

Ciao ragazzi, sono nuovo di qui... utilizzo Tophost da pochissimo tempo e giusto in questi giorni ho iniziato ad avere problemi con la configurazione del FormMail (in questo caso quello di Matt's Script Archive)
Non so se lo conoscete, è piuttosto semplice anche nella configurazione: ho soltanto un dubbio riguardante la stringa
@valid_ENV = ('REMOTE_HOST','REMOTE_ADDR','REMOTE_USER','HTTP_USER_AGENT');
il Remote_User deve essere vuoto, come è scritto nel pannello informazioni CGI del dominio?...
A questo punto ho caricato il file perl sul server ed ho puntato il form su tale script che però, ahime dopo giorni di tentativi, ancora non funge. Mi compare puntualmente la scritta
CGI execution Error: Script FormMail.pl refuse execution
A causa del blocco che Tophost esegue dopo il tentativo di esecuzione di un script impostato su un diverso permesso CHMOD, ho prima ripristinato lo spazio web e successivamente impostato lo il CHMOD dello script a 750 ...ma ancora niente...

Ho provato un'altra strada, sostituendo lo script con un altro in perl che già ho utilizzato per altri domini e che ho la certezza funzioni... anche per questo, dopo l'invio, mi compare la stessa dicitura [... refuse execution].
In realtà, dovrei aspettarmi una casella di errore (poichè i campi sono vuoti e richiedono obbligatoriamente l'inserimento del testo) che invece non compare... questo mi fa capire che non c'è proprio comunicazione con lo script, tanto meno eseguito... interrotto in partenza...
Che consigli avete da darmi? Salto qualche passaggio? Aiutatemi...

Pino.

[pcguru]

uso molti script php che, per creare o uploadare files danno i chmod 777. adesso, non è che c'è un modo per far eseguire lo script di ripristino spazio web a determinati intervalli?

grazie

ciao

[ErEiSeR]

vorrei capire perchè se carico immagini dal mio script viene dato come chmod 640 e quindi non visualizzabile

[free]

Qual'è la nostra 'policy' in merito l'uso del CHMOD? Come si devono comportare gli utenti per cambiare il permesso di alcuni file e cartelle? Queste domande sono tra le più 'gettonate' tra i nostri clienti, sicuramente perchè i nostri spazi sono stati pensati e configurati in modo particolare.

La nostra configurazione è stata pensata con un occhio di riguardo alla sicurezza pur cercando di salvaguardare la libertà d'azione del cliente, anche se alla fine per un corretto operare nei nostri spazi bisogna tener conto di alcune norme ben precise.


E' possibile modificare i CHMOD nei nostri spazi?
Si è possibile! Per i file perl/cgi che vanno eseguiti e che risiedono nella cartella cgi-bin, il settaggio consigliato è 750. Se per caso si utilizza un settaggio diverso, come ad esempio il 777, o il 775 per un file, oppure si esegue un settaggio anche a 750 per una cartella scatta un meccanismo di protezione che blocca l'esecuzione dei file con conseguente errore.

E' possibile impostare i permessi di file e cartelle in qualsiasi parte del sito, prestando comunque attenzione che il settaggio a 777 fa scattare il meccanismo di protezione.

In questo ultimo caso la soluzione consiste nel cliccare su "Ripristino spazio web" dal pannello di controllo e poi prestare attenzione a come si impostano i permessi ai file.


Perchè non è consigliato settare a CHMOD 777 e fare questo genera un errore?
Perchè non serve! Solitamente gli spazi web hanno l'interprete PHP che gira come modulo di Apache e quindi come utente ad esempio "WWW", mentre i file che si caricano con il client FTP appartengono ad un utente diverso che chiameremo "FTP". Gli script PHP, dell'utente WWW, per poter utilizzare/manipolare i file che appartengono all'utente FTP hanno bisogno del permesso e qui entra in gioco il famoso CHMOD, comando che permette di cambiare i permessi ai file.
Nei nostri spazi è tutto più semplice perchè PHP ed FTP appartengono allo stesso utente "FTP" e quindi PHP non deve chiedere nessun permesso per andare a manipolare/utilizzare i file che sono stati creati con FTP.


Come mai se dite che è così semplice e tutto dovrebbe andare senza toccare nulla il mio script non funziona?
Il problema è che alcuni script sono programmati in modo 'ottuso' e non vediamo il motivo di abbassare le nostre difese per errori dovuti ad altri. Che significa questo? Purtroppo esistono alcuni script che non verificano se possono scrivere in un determinato file o meno, bensì controllano solo il CHMOD attuale di un determinato file e a priori se non trovano il valore desiderato "pensano" che tale file non sia scrivibile, quando invece a tutti effetti lo è. Quando viene effettuato un settaggio a 777 entra in funzione un controllo di sicurezza che blocca file e cartelle con questo settaggio. A questo punto bisogna cliccare su "Ripristino spazio web" dal pannello di controllo.

Ma è veramente più sicuro questo settaggio?
Si e per diversi motivi qui elencati:

• questo settaggio non permette il "cross-hacking", ossia se un utente fa girare nel proprio sito del software bacato ed un hacker riesce a bucare il sito potrà limitarsi a fare danni solamente in quel sito visto che ogni sito web ha un PHP con i permessi personalizzati;
• settare una qualsiasi cartella o file a CHMOD 777 significa consegnare le chiavi dell'intero server in mano agli hacker e questo non possiamo permetterlo.

Posso settare un file a 444 o a "sola lettura" senza incorrere in blocchi?
Certamente! Le configurazioni più restrittive rendono ancora più sicuri i file e le cartelle presenti nello spazio web.

Ma va settato a localhost?