Php 5.3.x

[Kuro]

Come forse sapete da qualche giorno è stata rilasciata la prima versione (stabile) della famiglia 5.3 di php.
Quanti di voi provider hanno già pianificato (o stanno pianificando) un upgrade a questa versione?
In particolare vorrei capire cosa spinge un provider ad aggiornare al "nuovo" o a mantenere il "vecchio".

[webhostingperte]

Ciao io per il momento penso proprio di non installarla, rimango con il mio 5.2.9 poi più avanti valuterò pro e contro e se veramente vale la pena di aggiornare dei server che al momento non hanno problemi...
Ottimo post comunque..

[Antonio]

Viste le modifiche che hanno apportato, penso che passerà un bel pò di tempo prima di vedere la versione 5.2 soppiantata dalla 5.3 (PHP: Backward Incompatible Changes - Manual)

Chi può permetterselo affiancherà alla attuale 5.2.10 la 5.3

PS:
Leggo con piacere che hanno deprecato un pò di direttive e funzioni che creavano più problemi di quelli che risolvevano (PHP: Deprecated features in PHP 5.3.x - Manual).

Per i namespace, invece, trovo veramente infelice l'utilizzo del backslash.

[e-maging.ch]

Anche noi come webpertutti per ora ci teniamo l'attuale versione php

più in la (molto più in la) si passerà alla 5.3

saluti

[guest]

Be, la compatibilità a ritroso non mi sembra così compromessa da non installare php 5.3.

Mi sembra che le uniche problematiche che possano venir fuori sono date da queste direttive deprecate: PHP: Deprecated features in PHP 5.3.x - Manual

(Finalmente han tolto il supporto al safe_mode, generava più problemi di quelli risolti. Mi chiedo invece quando si decideranno ad includere nel ramo ufficiale la patch exec_dir)

[Antonio]

Be, la compatibilità a ritroso non mi sembra così compromessa da non installare php 5.3.

Mi sembra che le uniche problematiche che possano venir fuori sono date da queste direttive deprecate: PHP: Deprecated features in PHP 5.3.x - Manual

Per le funzioni deprecate, dato che sono solo deprecate e non eliminate, dovrebbero essere utilizzabili ancora ma daranno l'errore E_DEPRECATED.

Il problema sono le modifiche fatte ad altre funzioni che, soprattutto negli script scritti meglio, potrebbero essere largamente utilizzate (parlo delle "magic function").

(Finalmente han tolto il supporto al safe_mode, generava più problemi di quelli risolti. Mi chiedo invece quando si decideranno ad includere nel ramo ufficiale la patch exec_dir)

Nel mio PS mi riferivo proprio a quelle direttive ed al magic_quotes, finalmente si sono decisi a scindere quelle che è la configurazione delle funzionalità dell'engine da quella che è la sicurezza (che non dovrebbe avere niente a che fare con php e dovrebbe essere fatta a monte).

Antonio

[guest]

la sicurezza (che non dovrebbe avere niente a che fare con php e dovrebbe essere fatta a monte).

verissimo, ma vuoi mettere che aiuto danno un open_basedir e un exec_dir ?

Purtroppo non sempre è possibile usare suPHP con un utente univoco per ciascun virtualhost e senza openbasedir sarebbe un macello, una vera carneficina, ogni utente php potrebbe accedere a tutti gli altri siti.

[Antonio]

verissimo, ma vuoi mettere che aiuto danno un open_basedir e un exec_dir ?

Purtroppo non sempre è possibile usare suPHP con un utente univoco per ciascun virtualhost e senza openbasedir sarebbe un macello, una vera carneficina, ogni utente php potrebbe accedere a tutti gli altri siti.

Per come la vedo io:

- mod_php si usa se son solo sul server
- php in fastcgi/cgi andrebbe usato per tutto il resto e, una volta che hai settato suexec, hai messo in jail apache+php e fai creare le cartelle con i giusti permessi utente:gruppo, mi spieghi come l'utente A va a farsi i fatti dell'utente B o i fatti tuoi gironzolandoti nella /etc?

PS: a morte suPHP che è un performance-kill...

[guest]

- mod_php si usa se son solo sul server

Purtroppo, non sempre è possibile.
Io stesso ho la maggiorparte dei server con mod_php.
Vuoi perchè son server vecchi, vuoi perchè son stati fatti, a loro tempo, da altri, cambiare mod_php in favore di fastcgi su un server di qualche anno fa non è il massimo.
Potresti ritrovarti con una macchina ko.
Meglio evitare di mettere "il culo davanti ai calci"

- php in fastcgi/cgi andrebbe usato per tutto il resto e, una volta che hai settato suexec, hai messo in jail apache+php e fai creare le cartelle con i giusti permessi utente:gruppo, mi spieghi come l'utente A va a farsi i fatti dell'utente B?

Semplicemente così:
file in 777.
Vallo a spiegare agli utenti che non devono mettere 777...
Lo fanno comunque, ed in tal caso, l'utente A può andare verso l'utente B.

Poi, la sicurezza non è mai troppa, tutto quello che te dici va fatto, ma io preferisco mettere anche un livello di protezione aggiuntivo dato dal basedir.
Di certo male non gli fa, può solo migliorare la sicurezza generale.

[Antonio]

Purtroppo, non sempre è possibile.
Io stesso ho la maggiorparte dei server con mod_php
Vuoi perchè son server vecchi, vuoi perchè son stati fatti, a loro tempo, da altri, cambiare mod_php in favore di fastcgi su un server di qualche anno fa non è il massimo
Potresti ritrovarti con una macchina ko.
Meglio evitare di mettere "il culo davanti ai calci"

In quel caso, se sono server vecchi ed in produzione, o non si tocca più l'engine php e si rischia sotto il profilo della sicurezza (e qui gli dici chiaramente che non ti assumi alcuna responsabilità nel caso di "incidenti"), oppure si dice al cliente che è necessario intervenire aggiornando e, quindi, necessariamente andrà rivista la configurazione della macchina con un seguente periodo di testing/fixing dell'applicazione.

Non si possono tenere sistemi legacy connessi ad internet dove hai non la probabilità che ti buchino, ma la certezza (murphy docet)

Semplicemente così:
file in 777.
Vallo a spiegare agli utenti che non devono mettere 777...
Lo fanno comunque, ed in tal caso, l'utente A può andare verso l'utente B.
Poi, la sicurezza non è mai troppa, tutto quello che te dici va fatto, ma io preferisco mettere anche un livello di protezione aggiuntivo dato dal basedir.
Di certo male non gli fa, può solo migliorare la sicurezza generale.

In quel caso che colpa ne hai tu, php o il mondo intero se il tuo cliente è così altruista e generoso da permettere al "mondo" di far visualizzare i suoi file?

E, comunque, dato che un sistema del genere può permettersi anche di girare con permessi del tipo "770", basta uno shell script che ti fa un check periodico su file & cartelle oppure, se vuoi essere brutale, che vada direttamente ad eseguire un chmod -R o=- /cartella

Con questo volevo dire che se anche togliessero open_basedir, non sarebbe un grosso problema se chi si occupa della gestione sa il fatto suo

Saluti,
Antonio

[Derevko]

Semplicemente così:
file in 777.
Vallo a spiegare agli utenti che non devono mettere 777...
Lo fanno comunque, ed in tal caso, l'utente A può andare verso l'utente B.

con fastcgi+suexec 777 non ha più senso, ha invece senso proibirlo nella configurazione dell'ftpd

[Antonio]

con fastcgi+suexec 777 non ha più senso, ha invece senso proibirlo nella configurazione dell'ftpd

Fosse così semplice , anche php può creare files e gli script più vecchiotti o conservativi tendono ad assegnare permessi anche al gruppo other perché con mod_php i files vengono creati con l'user:group del webserver...

Quindi, per riparare al danno fatto dagli script, un check periodico conviene sempre farlo, te lo dico per esperienza

[Derevko]

Fosse così semplice , anche php può creare files e gli script più vecchiotti o conservativi

Sì ma una riga di bash in cron.daily è altrettanto semplice

[Antonio]

Sì ma una riga di bash in cron.daily è altrettanto semplice

Leggi il mio intervento (precedente al tuo post)

E, comunque, dato che un sistema del genere può permettersi anche di girare con permessi del tipo "770", basta uno shell script che ti fa un check periodico su file & cartelle oppure, se vuoi essere brutale, che vada direttamente ad eseguire un chmod -R o=- /cartella

Antonio

[guest]

Rispondo a tutti, non sto a quotare tutto di tutti.

E' vero che i sistemi vecchi sono bucabili, ma è altrettanto vero che un sistema vecchio senza open_basedir sarebbe un suicidio.
Cosa voglio dire con questo? Che nonostante il sistema sia bucabile perchè non ha php all'ultima versione e bla bla bla bla, open_basedir limita (e non poco) i danni.
tutto qui. Meglio poco, che niente.

E poi, che fastidio vi da open_basedir?
Se c'è, tanto meglio. Meglio una features in più, che una in meno, quando si parla di sicurezza. (e non sto di certo dicendo che non bisogna sistemare il sistema "a monte" anzi, è la prima cosa da fare.
Ma come surplus io attivo sia open_basedir che exec_dir)

Per quanto riguarda l'ftp, sinceramente, non sapevo che si potessero limitare i file in 777. Non ci ho mai guardato, buono a sapersi.

Poi non capisco una cosa: perchè non vi piace questo basedir?
Un utente non deve fare niente fuori dal suo dominio, per cui, tanto vale confinarlo li dentro. (oltre alla sicurezza del server che è fondamentale)

La sicurezza non è mai troppa, più contromisure adotti meglio è.