>secondo me a livello di sicurezza sarebbe meglio creare una
>interfaccia web e comunicare via http sulla porta 80 col db
>credo che ti basti poco per modificare il plugin e farlo funzionare in
>questo modo
Non vi e' dubbio su questo.
Ma si sa' le scorciatoie sono sempre piu' attraenti.
La cura migliore in questi casi e' batterci la testa direttamente.
Andrea Peri
La cura migliore in questi casi e' batterci la testa direttamente.
Concordo pienamente!!! 8 )
Anche perchè francamente non saprei da dove partire per riscrivere il plugin. Suggerimenti?
Mmh… niente di particolare.
Salvo che forse quello che non si e’ percepito nei precedenti messaggi e’ che quando parlo di livello di sicurezza non parlo solo di protezione da intrusi ma anche sicurezza di ricevere quello che si e’ spedito.
Che e’ un “pochino” piu’ importante 
Tornando al tuo caso:
te ipotizzi una comunicazione fisica senza uno strato sovrastante.
Ovvero fare viaggiare su internet direttamente il pacchetto destinato al dbms.
E’ come spedire un vaso di vetro per corriere senza imballarlo in una scatola. Puo’ arrivare anche rotto. Questo nessuno te lo garantisce.
Ma se arriva proprio in briciole allora almeno ci si accorge che e’ rotto. pazienza, ma se arriva con qualche piccola “incrinatura” magari te ne accorgi solo se lo guardi con attenzione.
Se poi la percentuale di vasi rotti e’ bassissima, hai risparmiato , se e’ elevata ci rimetti.
Far viaggiare pacchetti su interne te’ la medesima cosa.
Infatti far viaggiare su internet pacchetti di dati progettati per viaggiare su una rete sicura e con dei fail-over bassissimi (una rete interna), comporta che viaggiano con un supporto di sicurezza ridotto perche’ nato per viaggiare su una rete affidabile (la rete interna).
Volendo scendere ancora di piu’ sulla matematica che ci sta’ dietro (la parte che mi piaceva di piu’).
I pacchetti che transitano sulle reti (tutte le reti nessuna esclusa) hanno dei meccanismi di rilevamento errore (crc) che sono capaci di rilevare un certo numero di bit errati e in tal caso chiedono la ritrasmissione.
Contrariamente a quello che si crede, l’evento “bit errato” avviene in continuazione anche su una rete interna. La differenza è che su una rete affidabile avviene di rado (ma avviene) su una rete poco affidabile avviene con una frequenza molto maggiore.
Questo e’uno dei motivi piu’ frequenti di quello che si chiama sovraccarico della rete (parlo di rete interna).
Ovvero Se per qualche ragione un router o una scheda comincia a funzionare male, manda a giro dei pacchetti errati, gli altri client chiedono la ritrasmissione in continuazione ed ecco che la rete si satura con una ondata di richieste che finiscono per rallentare tutti e riempire completamente la banda.
Tornando al discorso originale:
Le capacita’ di rilevamento degli errori sono commisurate al sistema su cui opereranno.
Anche perche’ per fare il controllo si deve sprecare spazio. Tieni presente che si parla di pacchettini che hanno dimensioni di 1500 bytes. Fai il conto di quanti ce ne vogliono per spedire (o anche leggere) 1 Mbytes capisci che cosa questo comporta su una rete.
Nel momento in cui li fai passare su un sistema a bassa affidabilità senza aumentarne la capacità di controllo e quindi di rilevazione degli errori, ti esponi al rischio che chi riceve non si accorga che un pacchetto e’ arrivato errato.
Tutto questo per dire.
Che per far funzionare il sistema di colloquio diretto.
Conviene, se postgres lo consente (ma credo di si’) di impostarlo con dei parametri o scegliere dei protocolli piu’ adeguati per il colloquio su internet.
Cio’ comportera’ una lentezza maggiore rispetto a quello che potresti avere se vai con i protocolli per rete interna, ma almeno sei piu’ sicuro che i dati non subiranno errori che poi ti ritrovi sotto forma di dati errati nel db (se ti va bene) oppure cose incomprensibili per chiunque (molto piu’ probabile).
Poi ci sarebbe il discorso della sicurezza da intrusi, ovvero da interferenze esterne sul singolo pacchetto che transita su internet, ma quello e’ piu’ soggettivo. Voglio dire che il rischio e’ ben presente , molto piu’ elevato di quanto tu passa immaginare, ma se non ti importa questo lo decidi te.
Tieni comunque presente che e’ solo teoria.
Poi serve la pratica.
L’unica strada e’ provare. Quantomeno ti levi il dubbio.
Ciao,
Il giorno 13 maggio 2010 14.55, Luca Mandolesi <mandoluca@gmail.com> ha scritto:
La cura migliore in questi casi e' batterci la testa direttamente.Concordo pienamente!!! 8 )
Anche perchè francamente non saprei da dove partire per riscrivere il plugin. Suggerimenti?
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
Tutto questo per dire.
Che per far funzionare il sistema di colloquio diretto.
Conviene, se postgres lo consente (ma credo di si’) di impostarlo con dei parametri o scegliere dei protocolli piu’ adeguati per il colloquio su internet.
Cio’ comportera’ una lentezza maggiore rispetto a quello che potresti avere se vai con i protocolli per rete interna, ma almeno sei piu’ sicuro che i dati non subiranno errori che poi ti ritrovi sotto forma di dati errati nel db (se ti va bene) oppure cose incomprensibili per chiunque (molto piu’ probabile)
Intanto grazie per la risposta. Ci sono errori che noi umani non potremmo neppure immaginare! 8 )
Faccio mio questo consiglio e proverò a chiedere sui forum di postgres e guardare un po’ di doc!
Poi farò le care prove e vediamo cosa succede.
Grazie.
Luca
On Fri, May 14, 2010 at 08:30:33AM +0200, Andrea Peri wrote:
Infatti far viaggiare su internet pacchetti di dati progettati per viaggiare
su una rete sicura e con dei fail-over bassissimi (una rete interna),
comporta che viaggiano con un supporto di sicurezza ridotto perche' nato per
viaggiare su una rete affidabile (la rete interna).
A dire il vero si utilizza TCP/IP che invece è nato proprio per
garantire connessioni affidabili su canali poco affidabili.
Il tutto funziona con il meccanismo degli acknowledgment e
ritrasmissione in caso di errore.
Quindi è sufficiente che il client, durante la trasmissione dati,
verifichi le condizioni di errore, il canale TCP/IP è garantito
che le segnala.
--
Niccolo Rigacci
Firenze - Italy
Quindi è sufficiente che il client, durante la trasmissione dati,
verifichi le condizioni di errore, il canale TCP/IP è garantito
che le segnala.
Domanda da dummy: con “che il client verifichi le condizioni”, significa che devo creare un sistema che controlli il TCP/IP in maniera indipendente dal quello che manda le query al DB?
Per capirsi: quale sarebbe una buona domanda da porre sul forum di python? Capire se c’è un modulo che fa un buon controllo del canale TCP/IP prima di mandare la query?
Scusate la crudità, ma è un campo al quale non sono avvezzo.
Come dicono nei quiz in TV alla domanda:
presentatore: Signora da dove chiama?
signora a casa: Ehm, uuh, posso avere un aiutino??
ciao
luca
Domanda da dummy: con "che il client verifichi le condizioni", significa che
devo creare un sistema che controlli il TCP/IP in maniera indipendente dal
quello che manda le query al DB?
il protocollo TCP/IP è implementato in tutti i sistemi operativi a
livello di kernel quindi non ti devi preoccupare di niente nel tuo
programma. Devi solo verificare i vari timeout per evitare di stare in
attesa infinita se la connessione cade, ma anche questo è spesso
gestito dalle librerie di base.
Per quanto riguarda l'integrita dei dati sul db risolvi il problema
mettendo le query di aggiornamento tutte in una transaction (BEGIN;
... COMMIT;) così se qualcosa va male non viene scritto niente.
Se hai aperto la porta 5432 di postgres verso l'esterno (o meglio
verso alcuni indirizzi IP) non ti dovresti preoccupare di niente se
non di qualche delay rispetto all'uso locale ed eventualmente qualche
timeout che scade. Per fortuna il TCP/IP ha quasi 40 anni ed una
tecnologia abbastaza matura 
Ciao,
Stefano
On Fri, May 14, 2010 at 11:27:38AM +0200, Luca Mandolesi wrote:
>
Domanda da dummy: con "che il client verifichi le condizioni", significa che
devo creare un sistema che controlli il TCP/IP in maniera indipendente dal
quello che manda le query al DB?
Se il tuo client è scritto in Python suppongo che usi una
libreria per parlare con Postgres, io ad esempio uso psycopg2.
Ad ogni chiamata di funzione, ad esempio la connect(), devi
verificare che non ci siano errori, qualcosa del tipo:
try:
conn = psycopg2.connect(db_connect)
curs = conn.cursor()
except:
conn = None
curs = None
logger.error("Cannot connect to the database")
Anche l'esecuzione di un'istruzione SQL:
try:
curs.execute(sql, ....)
conn.commit()
except:
logger.error("INSERT failed: %s" % (sys.exc_info()[1]))
conn.rollback()
--
Niccolo Rigacci
Firenze - Italy
Perfetto, si, uso psycopg passando poi da sqlalchemy, quindi questi controlli già li faccio.
Bene, grazie mille.
ciao
Luca
2010/5/14 Niccolo Rigacci <niccolo@rigacci.org>
On Fri, May 14, 2010 at 11:27:38AM +0200, Luca Mandolesi wrote:
Domanda da dummy: con “che il client verifichi le condizioni”, significa che
devo creare un sistema che controlli il TCP/IP in maniera indipendente dal
quello che manda le query al DB?Se il tuo client è scritto in Python suppongo che usi una
libreria per parlare con Postgres, io ad esempio uso psycopg2.Ad ogni chiamata di funzione, ad esempio la connect(), devi
verificare che non ci siano errori, qualcosa del tipo:try:
conn = psycopg2.connect(db_connect)
curs = conn.cursor()
except:
conn = None
curs = None
logger.error(“Cannot connect to the database”)Anche l’esecuzione di un’istruzione SQL:
try:
curs.execute(sql, …)
conn.commit()
except:
logger.error(“INSERT failed: %s” % (sys.exc_info()[1]))
conn.rollback()–
Niccolo Rigacci
Firenze - Italy
Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell’Associazione GFOSS.it.
440 iscritti al 15.3.2010
On Fri, May 14, 2010 at 11:09:03AM +0200, Niccolo Rigacci wrote:
On Fri, May 14, 2010 at 08:30:33AM +0200, Andrea Peri wrote:
>
> Infatti far viaggiare su internet pacchetti di dati progettati per viaggiare
> su una rete sicura e con dei fail-over bassissimi (una rete interna),
> comporta che viaggiano con un supporto di sicurezza ridotto perche' nato per
> viaggiare su una rete affidabile (la rete interna).A dire il vero si utilizza TCP/IP che invece è nato proprio per
garantire connessioni affidabili su canali poco affidabili.Il tutto funziona con il meccanismo degli acknowledgment e
ritrasmissione in caso di errore.Quindi è sufficiente che il client, durante la trasmissione dati,
verifichi le condizioni di errore, il canale TCP/IP è garantito
che le segnala.
Senza perdersi nei Massimi Sistemi di galileiana memoria, il problema
principale sono i timeout di connessione e connessi a questi il problema
di garantirsi contro modifiche parziali (-> inconsistenti) del DB.
Questo puo' essere fatto se si adotta in modo rigoroso una policy
strettamente transazionale nell'effettuare le modifiche (con rollback
automatico in caso di mancato commit esplicito). Tuttavia ci sono
sempre corner case e possibilita' di imbroccare situazioni
in cui la transazione non e' unica per errore o per motivi validissimi
e ci si espone quindi alla possibilita' di inconsistenza.
Gli stessi problemi comunque vanno considerati su WAN o LAN (non c'e'
scritto da nessuna parte che la LAN sia 'affidabile'...) quindi
il problema e' solo uno: scrivere applicazioni intrinsecamente
corrette dal punto di vista transazionale.
Poi potremmo parlare di OLTP e delle tecniche necessarie a garantire
che le transazioni *distribuite* (i.e. anche fra DB diversi) siano sempre
consistenti (se no staremmo freschi), ma per quello rimando a :
http://en.wikipedia.org/wiki/Online_transaction_processing
e penso che siamo ampiamente fuori dei termini.
--
Francesco P. Lovergine