Aruba, Plesk, Phpbb e permessi

[yum-iloveyou]

Tutti i problemi non inerenti la configurazione/gestione del tuo VPS. Ovvero, puoi porre domande sulle porte aperte del firewall, chiedere che facciano un controllo perché il tuo VPS è lento, chiedere perché la tal feature di Virtuozzo non funziona ma non chiedere quali permessi assegnare alla cartella né come farlo.

.. CUT ..

Aprirai un ticket per chiedere assistenza sistemistica che Aruba non è tenuta a fornirti oppure pagherai 50€/ora un sistemista capace?

corretto.

forse è necessario essere più espliciti in merito ai dubbi sollevati da ennekappa.

ennekappa, hai acquistato un servizio di fascia bassa.

secondo il fornitore, il canone mensile che tu versi copre l'equivalente di una quota di risorse di sistema, ogni extra al di fuori di quanto concordato viene fatturato.
rifletti, con un mese del canone mensile forse potresti pagare una sola ora/uomo per un sistemista.
difficilmente il fornitore ti regalerà l'equivalente di un suo costo: se non te lo rivende, non te lo fattura.

Grazie mille delle info yum!

prego. per il futuro ti consiglio di utilizzare la funzione "cerca" presente nel forum o google.

ciao

[Shazan]

Non mi sembra di aver chiesto COME cambiare i permessi di una cartella, ma evidentemente qui tutti sono talmente superiori che nemmeno leggono le richieste. Mai visto un forum così.

Io ho letto le tue richieste (e ti darò anche una spiegazione del tuo problema più sotto a dimostrazione di questo) e, nonostante questo, anche la mia impressione è che non sarebbe il caso che tu gestissi il VPS da solo ma che ti occorra un servizio managed o un sistemista. Se per risparmiare ti ostini ad andare avanti su questa strada, prima o poi saranno dolori. Ma è solo un consiglio, fai pure come ti aggrada.

Avevo chiesto se qualcuno ha idea del perchè Plesk nonostante abbia settato i premessi 777 non mi fa riconoscere alla pagina php di installazione di phpbb il fatto che quella cartella è scrivibile, probabilmente perchè deve avere un owner particolare oppure perchè i permessi bisogna darli da pannello di controllo cliccando sull'icona e non da ssh o viceversa, che ne so'.

Dovresti sapere che *chi* setta i permessi è irrilevante, l'importante è che siano corretti. Va bene impostarli anche via FTP.

I candidati "owner" nel caso in questione sono soltanto due:
1- l'utente sotto cui gira apache, che di solito è "nobody", "www-data" o qualcosa del genere a seconda di come è installato Apache. Se PHP gira come modulo di Apache, questo utente deve poter scrivere nella cartella in questione. Quindi o cambi l'owner, o metti i permessi a 777.
2- l'utente FTP se PHP gira con suexec, suPHP, PHPsuexec e simili. Neanche in questo caso serve che i permessi siano a 777, anzi in genere è vietato farlo e il sistema restituisce un internal server error o qualcosa del genere.

Detto questo, se l'utente è giusto ed i permessi sono corretti e continui a non riuscire a scrivere, significa che devi impostare il safe_mode di PHP su Off, infatti quando è su On, PHP non esegue nessuna operazione sui file il cui proprietario non è lo stesso di quello sotto cui gira PHP, neanche se i permessi sono a 777. Impostare PHP su Off è un rischio abbastanza serio per la sicurezza.

Insomma, tra 777 e safe_mode, se non sai cosa fai rischi grosso...

[Derevko]

Impostare PHP su Off è un rischio abbastanza serio per la sicurezza.

il safe_mode è un accrocchio mal riuscito e disegnato male. Gli stessi sviluppatori lo hanno ammesso già da tanto, non lo supportano più a livello upstream (i bug vanno in /dev/null), e in PHP 6 non ci sarà più.
Ormai qualsiasi script kiddie lo aggira senza troppi problemi, definire come un rischio abbastanza serio per la sicurezza la sua disattivazione è un po' inquietante.

[Shazan]

Mi fa piacere vedere che, pur di contraddirmi, ti sia fatto rivedere.

L'argomento safe_mode è controverso e non credo verrà risolto in questo post, non da noi almeno. Il motivo per cui su PHP 6 è stato rimosso non è perchè non sia utile, ma per il semplice fatto che molti sviluppatori si cullano sulle limitazioni imposte a livello di php.ini (non mi riferisco solo al safe_mode) e curano poco alcuni aspetti della sicurezza legati al codice. Togliendolo si spera in una maggiore attenzione in tal senso.

Che sia un rischio la sua disattivazione è un'opinione abbastanza diffusa, visto che vengono rimosse tutta una serie di limitazioni in un colpo solo, come si può vedere all'URL PHP: Functions restricted/disabled by safe mode - Manual

Se per te non è un rischio abbastanza serio, soprattutto in un ambiente non in suexec come presumo avvenga in questo caso, allora direi che puoi continuare ad inquietarti...

[Derevko]

Mi fa piacere vedere che, pur di contraddirmi, ti sia fatto rivedere.

Già, mi hanno linkato questo thread e chiesto di rispondere.

L'argomento safe_mode è controverso e non credo verrà risolto in questo post, non da noi almeno.

Che sia un layer in più è controverso, sì. ma che sia debole e pensato male no.

Il motivo per cui su PHP 6 è stato rimosso non è perchè non sia utile

È stato tolto perchè pensato male, inutile, crea più problemi che benefici, ci sono mille altre soluzioni a livello OS e non (vedi suexec) decisamente più efficaci e senza controindicazioni.

Se per te non è un rischio abbastanza serio, soprattutto in un ambiente non in suexec come presumo avvenga in questo caso, allora direi che puoi continuare ad inquietarti...

mi inquieta il contrario, non uso suexec/phpcgi/suphp/altro tanto uso il safe_mode.

[Shazan]

Già, mi hanno linkato questo thread e chiesto di rispondere.

Curiosa questa cosa... perchè non rispondevano direttamente anzichè mandare te...?

È stato tolto perchè pensato male, inutile, crea più problemi che benefici, ci sono mille altre soluzioni a livello OS e non (vedi suexec) decisamente più efficaci e senza controindicazioni.
mi inquieta il contrario, non uso suexec/phpcgi/suphp/altro tanto uso il safe_mode.

Tutto giusto, ma ti è sfuggito che stiamo parlando di un VPS di Aruba, basato su CentOS che di default non ha suexec/CGI/SuPHP, etc ma configurato con mod_php. Ergo, data la configurazione in questione, molto meglio tenere il safe_mode su On...

[Derevko]

Curiosa questa cosa... perchè non rispondevano direttamente anzichè mandare te...?

Perchè non è iscritto, e perchè questo argomento è stato più volte preso come esempio di un cattivo approccio alla sicurezza da parte di un noto esperto di sicurezza italiano.

Tutto giusto, ma ti è sfuggito che stiamo parlando di un VPS di Aruba, basato su CentOS che di default non ha suexec/CGI/SuPHP, etc ma configurato con mod_php. Ergo, data la configurazione in questione, molto meglio tenere il safe_mode su On...

"molto meglio" non è la stessa cosa di "un rischio abbastanza serio per la sicurezza", già è un passo avanti. In ogni caso io direi che molto meglio usare altro, non a caso il 90% dei CMS/apps non si installano nemmeno in safe_mode on.
Il safe_mode in questi anni è stato preferito da molti hoster perchè è di facile attivazione, e dà una (falsa) sensazione di sicurezza. Il rapporto costo/benefici è disastroso, è un po' come dare fuoco ad un cane quando ha le pulci.