[Gfoss] pubblicazione dati con postgres: a rischio la sicurezza del sistema?

[Andrea Peri]

>...
>Salve.
>Ovviamente la sicurezza assoluta non esiste, in informatica come in
>qualunque altro aspetto del mondo. Pero' non bisogna farsi prendere
>dalle paranoie (altrimenti quasi tutto internet non esisterebbe!); ci
>sono molti sistemi (alcuni li ha detti Sandro) per blindare il sistema,
>e poi bisogna vedere qual e' il livello di rischio accettabile in ogni
>situazione:
>- vuoi evitare che utenti non autorizzati vedano/scarichino informazioni?
>- vuoi evitare che ti buttino giu' il db?
> ...

Certo,
si puo' tutto.

ma quelle che dici te' sono problemi di superficie .

I veri problemi sarebbero altri, che non quelli di capire che un
utente deve vedere oppure no.

E la cosa si potrebbe dilungare , ma ovviamente qui il tono e' quello
di una discussione molto di superficie.
e oltretutto sono argomenti sostanzilamente teorici perche' poi nella
pratica le cose cambiano da prodotto a prodotto.

Per cui mi limito a dire che un conto e' dire proviamo tanto che ci costa.
E un altro e' fare una analisi a priori che rende conto di cosa e'
realmente fattbile e cosa non lo e'.

Domanda:
quanto bytes vengono scambiati tra un client gis e un dbms per
l'editing di un poligono in 2D dotato di 300 vertici espressi in
doppia precisione , e comprensivi di attributi alfanumerici ?
diciamo 4 kbytes ?
E che strategia di locking andrebbe adottata ?
lock esclusivo, shared, o altro ?

E poi che client si deve usare ?
Un client che committa solo a richiesta esplicita oppure un client che
fa' autocommit su ogni spostamento effettuato ?
Perche' le due strategie hanno implicazioni molto differenti.
E se sono sostanzialmente analoghe su un sistema di rete locale, anzi
forse quella autocommitante che e' piu' semplice forse
puo' interessare di piu'.
In un sistema via internet un client autocommittante aumenterebbe
esponenzialmente il traffico esaurendo la banda disponibile.

Tutte domande a cui dare una risposta non e' facile.
Anche perche' i client sono tutti progettati per lavorare su una rete
locale dove e' logico e scontato non dover attendere 10 secondi  per
un trasferimento via rete locale della geometria e di conseguenza il
lavoro e il tempo necessario e' tutto "inside dbms", mentre il
data-trasnfer e' quasi immediato.
Qui, invece esiste una zona grigia: "Il trasferimento di rete".

Nel corso del quale il dbms ancora non ha ricevuto i dati e non puo'
committarli, pero' il client da' per scontato, avendoli gia' spediti
che sono in pancia nel db. E di conseguenza si aspetta che il dbms
possa rimandarglieli subito per ripresentarli a video dopo che sono
stati committati.

Questo apre un problema tecnico.
Le cui conseguenza  sono imprevedibili perche' cambiano in base al
tipo di client e in soldoni al codice che il programmatore ha scritto.

Non e' escluso infatti che se il client, subito dopo aver fatto un
invio al db per il salvataggio, facesse una richiesta di ricevere le
nuove geometrie, gli ritornino i vecchi dati.
Il tutto solo perche' i nuovi ancora non sono giunti a destinazione
nella pancia del dbms.
Pensa te cosa succederebbe ....

Ciao,

-- 
~~~~~~~~~~~~~~~~~
§       Andrea              §
§         Peri                 §
~~~~~~~~~~~~~~~~~