[VBA] E' vero, è molto pericoloso!!!

[Mancho]

Forse avrei dovuto inserire questa discussione nella sezione sicurezza, ma visto che comunque si tratta di programmazione, è probabile che questo sia più adatto.

Stavo facendo esperienza con la connessione ai database tramite il linguaggio VBA, nella fattispecie quello di WORD e mi sono messo a fare alcune prove tra la miriade di comandi che la guida spiega in maniera molto confusa. Tra successi (pochi) e delusioni (tante), mi sono inbattuto in questo codice presente nella guida in linea ed erroneamente l'ho creduto adatto al mio scopo:

ActiveDocument.MailMerge.CreateDataSource _
    Name:="C:\NomeCartella\NomeDatabase.mdb", _
    HeaderRecord:="Name, Address, City, State, Zip"

L'ho adattato al mio database ed ho provato a farlo girare, ma purtroppo non succedeva niente. Guardando il codice più attentamente ho notato che si trattava di istruzioni atte alla creazione di un nuovo database, non a connettersi ad uno esistente e pertanto ho iniziato a cercare altre soluzioni ma, con mio estremo stupore, quando ho tentato di riattivare la connessione al database con il semplice "MailMerge", ho visto che non funzionava più. Ebbene, quelle semplici righe, hanno messo in atto una catastrofe: database originale sostituito dal nuovo creato da codice, senza nemmeno uno straccio di richiesta di conferma sostituzione. Per carità, per fortuna non ho subito danni grazie al backup, ma mi sembra lo stesso assurdo che alcune semplici righe di codice possano cancellare un file così facilmente, anche perché non cancellano solo i database, ma qualsiasi altro file si indichi.

Quando si tenta di creare un file che ha lo stesso nome di uno già presente sul disco e si tenta di inserirlo nella stessa cartella di quest'ultimo, il sistema operativo non lo permette oppure, in caso di tentativo di cancellazione, anche quella più brutale con SHIFT-CANC, ci viene comunque chiesta conferma, nel caso sopra esposto invece tutto è stato fatto in maniera assolutamente invisibile all'utente.

E' vero, il VBA può essere pericoloso ed è altrettanto vero che i software ci avvertono prima di eseguire macro, ma credevo che per creare problemi fosse necessaria una programmazione ben più raffinata ed invece ho potuto constatare che per fare seri danni, bastano le conoscenze di un neofita.

Mah!!!

[cdimauro]

Non vedo cosa ci sia di così scandaloso: è un'API che serve, appunto, a creare un nuovo database.

Non fa parte dei suoi requisiti quella di controllare se il file esiste, ed eventualmente chiedere conferma: queste erano cose che avresti dovuto fare TU.

Come hai sottolineato, ci sono SOFTWARE che eseguono controlli e chiedono conferme. Ebbene, quella che hai citato è un'API che viene richiamata da un software e... il software è il tuo!

L'errore, dunque, è tutto tuo.

[71104]

@Mancho: embe', se tu scarichi un documnento Word da un allegato email proveniente dal tuo stesso indirizzo e lo apri eseguendo le macro e non hai neanche un account limitato... fatti tuoi

perché ragionando come fai tu allora tu non ha idea di cosa potrebbe fare un neofita in C

#include <stdlib.h>
#include <stdio.h>

int main() {
	rename("C:\\Windows\\System32\\ntoskrnl.exe", "C:\\Windows\\System32\\ops");
	printf("ops... :rolleyes:\n");
	getchar();
	return 0;
}

[Steel Jans]

in tutti i linguaggi di programmazione viene offerta piena libertà a chi scrive codice. E' questo è un bene perché per chi scrive applicazioni è importantissimo avere pieno controllo su tutto.
Il fatto che quelle poche righe di codice sovrascrivano un db esistente senza chiederne conferma è normalissimo. Questo fa parte della flessibilità che ci viene offerta dai software di sviluppo. Se un software da noi scritto ha qualche problema la causa è insita in un nostro errore.
Quindi è buon norma, quando si scrive un software, fare prima un attenta analisi di tutte le possibili situazioni in cui possiamo trovarci. Così facendo si eliminano gran parte delle brutte sorprese.

[Mancho]

Dalle vostre risposte si evince che siete, se non esperti, quanto meno appassionati di programazione e naturalmente difendete il vostro mezzo di espressione e/o di lavoro e questo è sicuramente encomiabile. La mia non vuol essere una critica ai linguaggi di programmazione in generale, ho solo riportato una mia esperienza negativa, (non grave, viste le copie di sicurezza), che potrebbe ripetersi nei PC di chiunque.

So bene, anche se non sono esperto di nessun linguaggio di programmazione che questi, data la loro potenza e flessibilità, possono essere devastanti, ma mi sembra ancora molto strano che senza utilizzare programmazioni a basso livello, con compilazione del codice ed accesso diretto alle parti più nascoste dell'hardware, si possano fare così tanti danni. Dopotutto ho soltanto scritto due righe in un linguaggio interno ad un software.

Non so come funzionano i PC a livello di gestione sistema operativo, (per me le API sono ancora quelle che fanno il miele), ma credo che una chiamata software che impone la sovrascrittura di un file esistente, debba essere in qualche modo intercettata dal sistema, sia che essa parta da un comando eseguito nella maniera classica, via mouse e/o tastiera, sia che provenga da un'istruzione VBA.

Chiedo troppo?

[cdimauro]

Sì, stai chiedendo al s.o. di fare qualcosa di più di quello che dovrebbe: far la balia agli utenti, siano essi programmatori o utilizzatori, per qualunque operazione.

Quando prima facevi l'esempio della rinomina del file, non è certo il s.o. che ti avvisa che esiste già un file con lo stesso nome, ma è l'APPLICAZIONE explorer.exe (che può aver scritto chiunque; infatti se ti fai un giretto ne esistono dei sostituiti scritti da altri utenti) che fa questi controlli e agisce per come il/i programmatore/i ha deciso di fare.

Da quel che scrivi è evidente che sei ancora alle prime armi. Quando avrai acquisito conoscenza del ruolo che esiste fra s.o. e applicazioni, tutto ti sarà più chiaro.

[_Claudio]

Effettivamente essendo VBA un linguaggio per macro, quindi spesso eseguito all'interno di altri programmi è sbalorditiva una cosa del genere, ma essendo VBA abbastanza vecchiotto...
Quindi mi stupirei di più se una cosa del genere succedesse in un linguaggio per macro o simili più "recente", finchè lo fa java o phyton tutto ok, è il programmatore a non applicare i buoni principi dell'ingegneria del software, ma se me lo facesse un linguaggio per macro di quelli nuovi mi incazzerei e non poco.
Per questo che sostengo e continuo a sostenere l'estrema utilità delle sandbox.

[okay]

Originariamente inviato da Mancho

Non so come funzionano i PC a livello di gestione sistema operativo, (per me le API sono ancora quelle che fanno il miele), ma credo che una chiamata software che impone la sovrascrittura di un file esistente, debba essere in qualche modo intercettata dal sistema, sia che essa parta da un comando eseguito nella maniera classica, via mouse e/o tastiera, sia che provenga da un'istruzione VBA.

Chiedo troppo?

No non chiedi troppo ma è quello che già avviene ovvero se elimini un file dal pc ti si apre la classica msgbox con su scritto "Vuoi eliminare il file? SI NO" oppure "vuoi sovrascrivere il file? SI NO".

Programmando invece è il programmatore che decide cosa fare!

Nel tuo caso "programmando" per esempio si usa creare un database vuoto per i "test" e poi lo si scrive si fà l'append oppure si elimina e poi magari si ricrea insomma si fanno dei test per vedere se tutto funziona... ma sempre con un database "vuoto" solo e solo per fare "test".

Volendo si può mettere un'ulteriore riga: "vuoi sovrascrivere il file? SI NO".

Ma Il vero programmatore non la usa la commenta perchè da solo fastidio in fase di debug. La decommenta solo a programma ultimato creando l'exe finale.

I "sarti" per esempio per fare un vestito costruiscono il modello di carta facendoci dei test se sbagliano taglio ridisegnano il modello su carta e fanno i tagli del caso fino a raggiungere il modello esatto. Poi dalle misure esatte del modello di carta possono finalmente tagliare il modello di stoffa.

Immagina se facessero il modello per i test direttamente sulla stoffa...

Immagina di usare un db per i test da 4/10 mb con su scritti tutti i comuni d'italia.
Immagina di cancellare questo db nei tuoi test... che fai riscrivi a mano tutti i comuni d'italia nel db?
Statisticamente farai un una "compilazione"... settimanale!



Avrai sicuramente sentito parlare di virus immagino.
Ebbene i virus non sono creati dal nulla ma li crea il programmatore.

Immagina se ti cimentavi a creare un virus. Il tuo ultimo post che hai fatto l'avresti fatto tra un paio di giorni in quanto saresti intento a formattare il tuo HD.
Un consiglio se un giorno ti venisse in mente di fare un virus, per capire come funziona, ti consiglio di programmarlo nel "Floppy A:" così se fai qualche "errore" (l'errore e sempre del programmatore MAI della macchina) formatti solo il dischetto.

Edit: Non giocare con il file "Regedit.exe"

[cdimauro]

Originariamente inviato da _Claudio

Effettivamente essendo VBA un linguaggio per macro, quindi spesso eseguito all'interno di altri programmi è sbalorditiva una cosa del genere, ma essendo VBA abbastanza vecchiotto...

VBA è un linguaggio a tutti gli effetti, per cui non niente di cui meravigliarsi.

Quindi mi stupirei di più se una cosa del genere succedesse in un linguaggio per macro o simili più "recente", finchè lo fa java o phyton tutto ok, è il programmatore a non applicare i buoni principi dell'ingegneria del software, ma se me lo facesse un linguaggio per macro di quelli nuovi mi incazzerei e non poco.

OpenOffice permette di utilizzare anche Python (ma anche altri) come "linguaggio di macro", e non mi sembra che soffra di particolari limitazioni.

Per questo che sostengo e continuo a sostenere l'estrema utilità delle sandbox.

Vero, ma in questo caso l'implementazione del "linguaggio di macro" andrebbe studiata appositamente (non mi riferisco al linguaggio di per sé, ma alle API che mette a disposizione: alcune andrebbero eliminate o rese accessibili con un sistema di livelli di privilegio), e questo richiede lavoro.

[_Claudio]

Originariamente inviato da cdimauro

VBA è un linguaggio a tutti gli effetti, per cui non niente di cui meravigliarsi.

OpenOffice permette di utilizzare anche Python (ma anche altri) come "linguaggio di macro", e non mi sembra che soffra di particolari limitazioni.

VBA è un linguaggio usato per le macro, così come python in openoffice, io non permetterei mai ad un linguaggio di macro di essere eseguito fuori da una sandbox, sia esso python, C o java, creando anche problemi ben peggiori di quello esposto.

Originariamente inviato da cdimauro

Vero, ma in questo caso l'implementazione del "linguaggio di macro" andrebbe studiata appositamente (non mi riferisco al linguaggio di per sé, ma alle API che mette a disposizione: alcune andrebbero eliminate o rese accessibili con un sistema di livelli di privilegio), e questo richiede lavoro.

Richiede lavoro... con tutto il tempo che si spende in cose molto più "cretine" fare una cosa del genere sarebbe parecchio UTILE, eviterebbe parecchi dei virus che ci sono in giro e tutta un'altra serie di effetti positivi...

[cdimauro]

Originariamente inviato da _Claudio

VBA è un linguaggio usato per le macro, così come python in openoffice, io non permetterei mai ad un linguaggio di macro di essere eseguito fuori da una sandbox, sia esso python, C o java, creando anche problemi ben peggiori di quello esposto.

Richiede lavoro... con tutto il tempo che si spende in cose molto più "cretine" fare una cosa del genere sarebbe parecchio UTILE, eviterebbe parecchi dei virus che ci sono in giro e tutta un'altra serie di effetti positivi...

Il tempo non lo vendono al mercato, e qui ce ne vorrebbe non poco.

[_Claudio]

Originariamente inviato da cdimauro

Il tempo non lo vendono al mercato, e qui ce ne vorrebbe non poco.

Ma la sicurezza è spesso nociva al tempo (pensa se per una cosa del genere perdessi un db intero... altro che tempo)

[71104]

Originariamente inviato da _Claudio

Effettivamente essendo VBA un linguaggio per macro, quindi spesso eseguito all'interno di altri programmi è sbalorditiva una cosa del genere, ma essendo VBA abbastanza vecchiotto...
Quindi mi stupirei di più se una cosa del genere succedesse in un linguaggio per macro o simili più "recente", finchè lo fa java o phyton tutto ok, è il programmatore a non applicare i buoni principi dell'ingegneria del software,

che c'entra l'ingegneria del software?

[Mancho]

Naturalmente rispetto le posizioni di tutti quelli che hanno risposto, ma torno a dire che per me un linguaggio relativamente semplice e poco potente come il VBA, se paragonato ai vari C, JAVA etc.. dovrebbe essere un po' più controllato, dopotutto per utilizzarlo non c'è bisogno di acquistarlo separatamente o di scaricarlo, pure se illegalmente, perché viene venduto con il pacchetto di Office, quindi teoricamente tutti gli utenti di quest'ultimo potrebbero usufruirne.

Ricordo ancora a tutti quelli che mi hanno gentilmente consigliato di effettuare prove in sicurezza che è proprio quello che ho fatto ed infatti ho provveduto a fare i backup sia del database che del file di Word che utilizzavo per la connessione. Ripeto: non mi sto lamentando perché ho perso il lavoro di anni, per fortuna non è successo, ma ho soltanto voluto denunciare un aspetto, secondo me negativo, di un software di programmazione e/o di un sistema operativo, dopotutto e qui dovrete darmi ragione, credo che i vari Windows, Mac OS, ma anche le più recenti versioni di Linux, fanno già molto da "balia" agli utenti meno esperti, perciò, visto che non stiamo parlando di Unix puro o altre diavolerie simili, credo che il mio appunto sia quantomeno lecito.

Torno a dire che per cancellare un file esistente senza che il software mi chiedesse conferma, non ho fatto altro che scrivere qualcosa che in pratica era un po' più di una macro e se di certo questa mia denuncia non servirà a diriimere la questione di sicurezza da me sollevata, almeno potrà evitare qualche disastro ad altri programmatori in erba.

Ciao a tutti e...


FATE I BACKUP PRIMA DI PROGRAMMARE!!!

[variabilepippo]

Torno a dire che per cancellare un file esistente senza che il software mi chiedesse conferma

E' proprio questo il punto, non stai USANDO un software, ne stai SCRIVENDO uno, quindi la responsabilità di decidere cosa fare, con quali modalità, quali messaggi di avvertimento mostrare (SE mostrarli) è a carico tuo.

[cdimauro]

Originariamente inviato da Mancho

Naturalmente rispetto le posizioni di tutti quelli che hanno risposto, ma torno a dire che per me un linguaggio relativamente semplice e poco potente come il VBA, se paragonato ai vari C, JAVA etc.. dovrebbe essere un po' più controllato, dopotutto per utilizzarlo non c'è bisogno di acquistarlo separatamente o di scaricarlo, pure se illegalmente, perché viene venduto con il pacchetto di Office, quindi teoricamente tutti gli utenti di quest'ultimo potrebbero usufruirne.

Il VBA non è "meno potente" dei linguaggi che hai citato.

Ricordo ancora a tutti quelli che mi hanno gentilmente consigliato di effettuare prove in sicurezza che è proprio quello che ho fatto ed infatti ho provveduto a fare i backup sia del database che del file di Word che utilizzavo per la connessione. Ripeto: non mi sto lamentando perché ho perso il lavoro di anni, per fortuna non è successo, ma ho soltanto voluto denunciare un aspetto, secondo me negativo, di un software di programmazione e/o di un sistema operativo, dopotutto e qui dovrete darmi ragione, credo che i vari Windows, Mac OS, ma anche le più recenti versioni di Linux, fanno già molto da "balia" agli utenti meno esperti, perciò, visto che non stiamo parlando di Unix puro o altre diavolerie simili, credo che il mio appunto sia quantomeno lecito.

Torno a dire che per cancellare un file esistente senza che il software mi chiedesse conferma, non ho fatto altro che scrivere qualcosa che in pratica era un po' più di una macro e se di certo questa mia denuncia non servirà a diriimere la questione di sicurezza da me sollevata, almeno potrà evitare qualche disastro ad altri programmatori in erba.

Ciao a tutti e...


FATE I BACKUP PRIMA DI PROGRAMMARE!!!

Sul resto quoto variabilepippo.

[Mancho]

Ultima nota: ho provato di nuovo a fare la procedura di creazione database tramite VBA, ma questa volta, il file che mi accingevo a sovrascrivere era protetto da scrittura. Risultato: il sistema operativo, explorer, pinco pallino o chi per loro NON mi ha concesso di cancellare il file esistente, semplicemente perché era protetto da scrittura, quindi questo significa che nonostante la chiamata da VBA, in qualche modo il S.O. è entrato in azione proteggendo il file.

Visto che quando si cancella un file o si cerca di sovrascriverlo con un file diverso, ma con lo stesso nome ed estensione il sistema ci chiede conferma, anche se si usa la procedura più brutale con SHIFT-CANC che non lo manda nemmeno nel cestino, credo che nel caso da me descritto debba verificarsi una cosa simile.

Il codice VBA che ho descritto crea un file nuovo sopra quello vecchio e ovviamente ne cambia le dimensioni, infatti nel mio caso il file è passato da circa 55.000 Kb. a soli 24. Non ho provato, ma sarei curioso di verificare se i software di recupero file cancellati, tipo Get Data Back o simili, riescono a ripristinarlo oppure non c'è più nulla da fare, perché in quel caso il problema sarebbe molto, molto più grave.

[variabilepippo]

Ultima nota: ho provato di nuovo a fare la procedura di creazione database tramite VBA, ma questa volta, il file che mi accingevo a sovrascrivere era protetto da scrittura. Risultato: il sistema operativo, explorer, pinco pallino o chi per loro NON mi ha concesso di cancellare il file esistente, semplicemente perché era protetto da scrittura, quindi questo significa che nonostante la chiamata da VBA, in qualche modo il S.O. è entrato in azione proteggendo il file.

Evidentemente non hai ben chiara la differenza esistente tra utente e programmatore né quella tra i compiti del sistema operativo e quelli del software applicativo. Finché non avrai fatto chiarezza su questi aspetti l'assenza di un avvertimento da parte del linguaggio di programmazione ti sembrerà "incomprensibile".

Se ogni operazione "potenzialmente" pericolosa mostrasse PER DEFAULT un messaggio di errore contro la volontà dello sviluppatore io avrei seri dubbi sulla *flessibilità* (eufemismo) del linguaggio in questione.

[Mancho]

Ok, è vero, non sono esperto, ma questo l'ho ammesso da solo e non mi pesa affatto farlo anche perché non è mia intenzione diventare programmatore, volevo solo automatizzare alcune procedure fastidiose e ripetitive, tutto qui. Torno a dire però che se un programmatore vuole avere più flessibilità, utilizzerà linguaggi più potenti ed adatti allo scopo, dopotutto, quando si vogliono ottimizzare alcune funzioni si torna a scrivere codice anche in assembler o cose simili.

Mi sembra che il mio penultimo post abbia dimostrato che la flessibilità di VBA che molti di voi hanno rimarcato, va a farsi friggere semplicemente se il meno esperto degli utenti clicca sulla casella attributi ed imposta il file su "sola lettura", pertanto voglio ancora sottolineare che secondo me, un qualche tipo di controllo sui file dovrebbe esserci, anche perché se un bravo programmatore volesse aggirarlo, non credo che avrebbe molti problemi a farlo e questo non avverrebbe per caso, ma con assoluta volontà dell'individuo di far fare al PC proprio quell'operazione.

Comunque, lasciando perdere ulteriori inutili discussioni, perché non proviamo a verificare se i software di recupero dati riescono a resuscitare il file sovrascritto? Io al momento non ho nessun software simile da installare, se c'è qualcuno che ce l'ha ed ha un po' di tempo da perdere, gli sarei grato se volesse provare.

Ciao a tutti!

[cdimauro]

Originariamente inviato da Mancho

Ok, è vero, non sono esperto, ma questo l'ho ammesso da solo e non mi pesa affatto farlo anche perché non è mia intenzione diventare programmatore, volevo solo automatizzare alcune procedure fastidiose e ripetitive, tutto qui. Torno a dire però che se un programmatore vuole avere più flessibilità, utilizzerà linguaggi più potenti ed adatti allo scopo, dopotutto, quando si vogliono ottimizzare alcune funzioni si torna a scrivere codice anche in assembler o cose simili.

Falso.

Mi sembra che il mio penultimo post abbia dimostrato che la flessibilità di VBA che molti di voi hanno rimarcato, va a farsi friggere semplicemente se il meno esperto degli utenti clicca sulla casella attributi ed imposta il file su "sola lettura", pertanto voglio ancora sottolineare che secondo me, un qualche tipo di controllo sui file dovrebbe esserci, anche perché se un bravo programmatore volesse aggirarlo, non credo che avrebbe molti problemi a farlo e questo non avverrebbe per caso, ma con assoluta volontà dell'individuo di far fare al PC proprio quell'operazione.

Questo, e lo ripeto, è perché non hai chiaro il ruolo dell'utente e del programmatore, e del s.o. e un software che ci gira.

Comunque, lasciando perdere ulteriori inutili discussioni, perché non proviamo a verificare se i software di recupero dati riescono a resuscitare il file sovrascritto? Io al momento non ho nessun software simile da installare, se c'è qualcuno che ce l'ha ed ha un po' di tempo da perdere, gli sarei grato se volesse provare.

Ciao a tutti!

Non posso aiutarti, mi spiace.