[JAVA] Permessi di accesso a file in Vista

[franksisca]

Originariamente inviato da PGI-Bis

Se l'utente ha copiato il file del programma in una cartella X deve avere almeno il permesso "write" per quella cartella altrimenti non avrebbe potuto creare il file del programma in quel punto.

e anche tu hai ragione

[fero86]

Originariamente inviato da banryu79

Percui quando fai un'affermazione di questo tipo:

[...]

per me è poco circostanziata, ovvero i motivi per cui Java sucks (così come tutti gli altri linguaggi, ognuno con i suoi sucks, chi più chi meno) sono altri, non di certo questo (che ripeto, non ha niente a che vedere con il linguaggio in se).

non ha niente a che vedere col linguaggio ma ha a che vedere con le API in dotazione, quindi comunque con la piattaforma Java.
é un sucks eccome, visto che tutte le sante volte che io devo scrivere un'applicazione desktop in Java (e non é che non mi sia capitato eh...) mi trovo di fronte sempre a questo stesso problema e la soluzione piu ragionevole alla fine risulta sempre essere quella di insozzare il proprio ramo di directories creando cosi un'applicazione per nulla "Vista-friendly".

Originariamente inviato da PGI-Bis

fero86, se l'idea di dover fare una libreria dinamica per windows ti spaventa così tanto vedrai che leggendo qua:

http://java.sun.com/docs/books/jni/html/jniTOC.html

e facendo riferimento a questo:

http://msdn.microsoft.com/en-us/library/aa139672.aspx

anche tu sarai in grado di farlo.

grazie per aver scritto il post piu inutile della storia.
ad ogni modo, che io sia in grado di farlo non vuol dire che sia una scelta ragionevole.

Originariamente inviato da PGI-Bis

[...] Personalmente aderisco alla prima ritenendo che distribuire un programma a terzi sia come essere invitati in casa d'altri: se ti fanno accomodare in salotto non significa che sei autorizzato a ficcare il naso nel ripostiglio.

molto divertente, ma non sono delle simpatiche metafore i motivi per cui determinate guidelines indicano che le applicazioni utente debbano scrivere in determinate cartelle. un'applicazione eseguita nel contesto di sicurezza dell'utente non dovrebbe mai scrivere nelle proprie cartelle di installazione perché l'utente non deve avere i permessi per scrivere da quelle parti (e intendo ne' per scrivere files esistenti ne' per creare nuovi files), altrimenti aumenta il rischio che lo faccia un virus visto che i virus nella quasi totalitá dei casi vengono eseguiti nel contesto di sicurezza dell'utente.

[malocchio]

Originariamente inviato da PGI-Bis

Se l'utente ha copiato il file del programma in una cartella X deve avere almeno il permesso "write" per quella cartella altrimenti non avrebbe potuto creare il file del programma in quel punto.

Originariamente inviato da fero86

molto divertente, ma non sono delle simpatiche metafore i motivi per cui determinate guidelines indicano che le applicazioni utente debbano scrivere in determinate cartelle. un'applicazione eseguita nel contesto di sicurezza dell'utente non dovrebbe mai scrivere nelle proprie cartelle di installazione perché l'utente non deve avere i permessi per scrivere da quelle parti (e intendo ne' per scrivere files esistenti ne' per creare nuovi files), altrimenti aumenta il rischio che lo faccia un virus visto che i virus nella quasi totalitá dei casi vengono eseguiti nel contesto di sicurezza dell'utente.

Concordo con fero: ammettiamo che un amministratore "installi" un programma system-wide, magari senza aver usato un installer ma scompattandolo manualmente, quindi in una cartella di sistema, in modo che tutti possano avviarla. Ovviamente gli utenti normali non hanno permessi di scrittura in tali cartelle, o non dovrebbero averli. Quindi sembra più plausibile avere tutto già pronto per l'esecuzione e scrivere su disco solamente le preferenze dell'utente, appunto nella home dell'utente.
Vedi che ci sono due strade:
- creo un'app portabile che scrive solo nella sua directory, perdendo la possibilità di avere un'unica copia nel sistema multi-utente.
- creo un'app (non è strettamente necessario un installer) che si avvia dalle cartelle di sistema e va a scrivere singolarmente per ogni utente le informazioni personali nella home

Quindi applicazione portabile non è sinonimo di applicazione stand-alone, a questo punto.

[banryu79]

Originariamente inviato da fero86

non ha niente a che vedere col linguaggio ma ha a che vedere con le API in dotazione, quindi comunque con la piattaforma Java.
é un sucks eccome, visto che tutte le sante volte che io devo scrivere un'applicazione desktop in Java (e non é che non mi sia capitato eh...) mi trovo di fronte sempre a questo stesso problema e la soluzione piu ragionevole alla fine risulta sempre essere quella di insozzare il proprio ramo di directories creando cosi un'applicazione per nulla "Vista-friendly".

Beh fero, che il discorso non avesse a che vedere con il linguaggio ma con la piattaforma mi sembrava cristallino, l'avevo anche specificato:

Originariamente inviato da banryu79

C'è anche da dire però, a voler mettere i puntini sulle "i", che è comunque fattibile, e non dipende dal linguaggio, quanto dalla piattaforma, che a differenza del citato C# che si appoggia a librerie create dagli stessi autori del sistema operativo su cui può girare, con tutti i fichissimi binding alle WinAPI (e vorrei anche vedere), Java non nasce di suo per lavorare specificatamente con Windows (anche se sicuramente i binding a metodi messi a disposizine nel JDK standard che ti permettano di accedere a variabili di ambiente well known come %APPDATA% in Windows possono benissimo essere implementati).
...

Quindi alla fine il tuo discorso, se non ho capito male, è che la piattaforma Java "sucks" perchè non ha una API specifica per il recuperare il percorso memorizzato nella variabile di ambiente %APPDATA% dei sistemi Windows?

[fero86]

Originariamente inviato da banryu79

Beh fero, che il discorso non avesse a che vedere con il linguaggio ma con la piattaforma mi sembrava cristallino, l'avevo anche specificato:


Quindi alla fine il tuo discorso, se non ho capito male, è che la piattaforma Java "sucks" perchè non ha una API specifica per il recuperare il percorso memorizzato nella variabile di ambiente %APPDATA% dei sistemi Windows?

fosse solo quello... la piattaforma Java "sucks" anche per altri motivi, di cui questo é legato alle API mentre molti altri sono legati al linguaggio

[franksisca]

Originariamente inviato da fero86

fosse solo quello... la piattaforma Java "sucks" anche per altri motivi, di cui questo é legato alle API mentre molti altri sono legati al linguaggio

scusa puoi elencare i motivi???


sinceramente aavendo studiato un bel pò di teoria non mi sembra catastrofica come la fai tu...

[malocchio]

Originariamente inviato da franksisca

scusa puoi elencare i motivi???


sinceramente aavendo studiato un bel pò di teoria non mi sembra catastrofica come la fai tu...

Originariamente inviato da fero86

fosse solo quello... la piattaforma Java "sucks" anche per altri motivi, di cui questo é legato alle API mentre molti altri sono legati al linguaggio

Sarà il solito YourLanguageSucks (link)

Ora passiamo al resto... quali sarebbero i "sucks" della piattaforma? Tralasciando le performance, che sono una partita persa.

[fero86]

vi risponderó con la tecnica di Hokuto del quote incrociato (franksisca-malocchio, franksisca-malocchio).

Originariamente inviato da franksisca

scusa puoi elencare i motivi???

Originariamente inviato da malocchio

Sarà il solito YourLanguageSucks (link)

Originariamente inviato da franksisca

sinceramente aavendo studiato un bel pò di teoria non mi sembra catastrofica come la fai tu...

non lo é assolutamente, Java é una piattaforma di ottima qualitá infatti; con i suoi sucks ma di ottima qualitá.

Originariamente inviato da malocchio

Ora passiamo al resto... quali sarebbero i "sucks" della piattaforma? Tralasciando le performance, che sono una partita persa.

vieni a sfidare me ad argomentare una tesi che tu mi hai messo in bocca quando poi tu ne sventoli un'altra ancora piu clamorosa? dove ho scritto che la piattaforma Java é piena di sucks che non riguardano il linguaggio?
sentiamo invece le tue argomentazioni: scrivi un benchmark, piglia un profiler e vediamo questi risultati catastrofici, e mi raccomando che sia tutto molto riproducibile.

[Frank1962]

ognuno ha i suoi modi di porsi, ergo, leggendo gli ultimi reply di questo thread, chiedo a PGI di non considerare più la continuazione di questa discussione a meno di non voler passare da Bis a Tris facendo perdere per un bel pò di tempo al forum un ottimo poster.....

[fero86]

Originariamente inviato da Frank1962

ognuno ha i suoi modi di porsi, ergo, leggendo gli ultimi reply di questo thread, chiedo a PGI di non considerare più la continuazione di questa discussione a meno di non voler passare da Bis a Tris facendo perdere per un bel pò di tempo al forum un ottimo poster.....

fake di PGI?

[banryu79]

Originariamente inviato da Frank1962

ognuno ha i suoi modi di porsi, ergo, leggendo gli ultimi reply di questo thread, chiedo a PGI di non considerare più la continuazione di questa discussione a meno di non voler passare da Bis a Tris facendo perdere per un bel pò di tempo al forum un ottimo poster.....

Solo una curiosità: perchè richiami l'utente PGI-bis?
(Sembra un richiamo, il post che hai scritto, quasi fosse un atto di moderazione).

Non mi pare che PGI abbia ne offeso ne alzato i toni della discussione...
E poi non mi pare neanche tanto bello moderare da utente un altro utente, quando i presupposti per farlo in modo sensato mancano...

Tutto questo senza volerti mancare di rispetto, ne incitare a un flame: è solo un desiderio di chiarezza da parte mia, perchè ho l'impressione di non capire bene la situazione che si è venuta a creare.

[PGI-Bis]

Non intendevo urtare la tua sensibiltà fero86 ma non vedo la ragione per cui tu debba insozzare la cartella dell'eseguibile Java se lo ritieni sbagliato. Quando dico che le librerie dinamiche devono essere poste nella cartella dell'eseguibile lo dico nel contesto di un'applicazione "portable". Non è l'unica opzione: si possono mettere in uno qualsiasi dei percorsi predefiniti per le librerie native della piattaforma java.

Se quando hai scritto le tue applicazioni desktop Java hai ravvisato la necessità insozzante è perchè non conoscevi l'alternativa. Non è che sia un delitto ma non è colpa della piattaforma.

Un programma portable non può scrivere in altre cartelle. E' creato nell'ottica di dover esistere su un drive rimuovibile: la configurazione ed i dati si muovono con il programma. Da ciò deriva la necessità di dover scrivere nella propria cartella.

Deriva anche la non condivisibilità dell'eseguibile: se due utenti avviano lo stesso programma i dati delle due sessioni andranno a confondersi nelle stesse cartelle, la rimozione del programma da parte di un utente si porta via anche i dati degli altri eccetera. Ci sono un tot di problemi logici oltre alla questione fisica dei permessi di accesso ai file.

L'installazione multiutente di un programma portabile deve necessariamente essere una replicazione dello stesso file su più percorsi altrimenti o il programma non è portabile o non ha bisogno di scrivere in locale o non funziona. Tertium non datur.

Comunque non è un obbligo quello di fare un'applicazione portabile: è una scelta.

Alternative almeno due. La prima è Java Web Start, specialmente per una intranet. La seconda è l'application server. Un Application Server J2EE a là Glassfish è prima di tutto un distributore di applicazione Java e incidentalmente di applicazioni web. Entrambe relegano alla preistoria aggiornamenti, patch, distribuzione, versioni diverse per os diversi eccetera eccetera.

Anche Squeak ha un sistema analogo (Monticello). L'installer è un po' masochistico.

[PGI-Bis]

Originariamente inviato da fero86

un'applicazione eseguita nel contesto di sicurezza dell'utente non dovrebbe mai scrivere nelle proprie cartelle di installazione perché l'utente non deve avere i permessi per scrivere da quelle parti (e intendo ne' per scrivere files esistenti ne' per creare nuovi files), altrimenti aumenta il rischio che lo faccia un virus visto che i virus nella quasi totalitá dei casi vengono eseguiti nel contesto di sicurezza dell'utente.

La questione è molto interessate.

E' un problema se un virus può scrivere nella cartella di un eseguibile in un sistema in cui ogni utente ha delle limitazioni di permesso?

Diciamo che c'è un eseguibile jar non certificato: il virus lo sovrascrive e l'utente lo avvia credendo che sia l'originale.

A questo punto il virus che fa? Direi nulla più di quanto potesse fare il programma originale. Cioè è comunque limitato dalle credenziali dell'utente. O sbaglio? Potrà mettere un programma in esecuzione automatica per qualsiasi utenza? No se non può farlo l'utente.

Forse è la condivisione delle applicazioni tra utenti con permessi diversi ad essere pericolosa più che la possibilità di scrivere nella cartella del programma.

E poi cambia qualcosa se chiudo la porta alla sovrascrittura dell'eseguibile e la lascio aperta ai plug-in che metto in application-data?

[malocchio]

Originariamente inviato da PGI-Bis

Forse è la condivisione delle applicazioni tra utenti con permessi diversi ad essere pericolosa più che la possibilità di scrivere nella cartella del programma.

Potresti spiegare il perché?

Originariamente inviato da PGI-Bis

E poi cambia qualcosa se chiudo la porta alla sovrascrittura dell'eseguibile e la lascio aperta ai plug-in che metto in application-data?

Beh una sovrascrittura dell'eseguibile coinvolgerebbe tutti gli utenti che lo usano, mentre una del plugin coinvolgerebbe solo l'utente che ha installato quel plugin nella cartella personale. O no?

Originariamente inviato da fero86

vieni a sfidare me ad argomentare una tesi che tu mi hai messo in bocca quando poi tu ne sventoli un'altra ancora piu clamorosa? dove ho scritto che la piattaforma Java é piena di sucks che non riguardano il linguaggio?
sentiamo invece le tue argomentazioni: scrivi un benchmark, piglia un profiler e vediamo questi risultati catastrofici, e mi raccomando che sia tutto molto riproducibile.

C'è stata un'incomprensione, allora. Pensavo che tu considerassi negativamente la piattaforma.

Perché mi inviti ad argomentare? E' storia che applicazioni scritte in Java siano più lente rispetto a molte altre...

ps. evita di dire che io ti ho sfidato per favore, stiamo chiacchierando

[PGI-Bis]

Originariamente inviato da malocchio

Potresti spiegare il perché?

Il perchè è nel rilievo che hai fatto sulla sovrascrittura.

Cioè se l'eseguibile è condiviso allora non devo poterlo cambiare, altrimenti consentiamo una migrazione dei permessi (il virus cambia l'eseguibile per un utente limitato che inietta del codice in una cartella di sistema quando è lanciato da un utente con i permessi di amministrazione del sistema).

Ma se tratto i programmi come fossero documenti e lascio che ognuno abbia la sua copia questo problema non c'è.

Forse le utenze non dorebbero essere gerarchiche ma mutualmente esclusive: l'amministratore non può pucciare il naso nei programmi dell'utente x perchè x potrebbe aver installato un malware che eseguito con permessi più ampi sarebbe in grado di provocare dei danni. Se vuole andare a sistemare qualcosa per l'utenza X allora deve usare le credenziali di X o un'emulazione delle credenziali di X.

[fero86]

Originariamente inviato da PGI-Bis

Non intendevo urtare la tua sensibiltà fero86 ma non vedo la ragione per cui tu debba insozzare la cartella dell'eseguibile Java se lo ritieni sbagliato.

é vero che é possibile ottenere il percorso della cartella corretta in cui mettere i dati prodotti dal programma, ma quel modo mi fa perdere la portabilitá. sul resto del tuo post sostanzialmente taglio perché hai scritto fiumi di parole basate su un concetto di portabilitá diverso da quello che io in genere leggo e intendo e non capisco cosa c'entra con quello che si stava dicendo: per me un'applicazione portabile é un'applicazione che gira cosi com'é (o con pochissima fatica da parte dello sviluppatore) su molte piattaforme differenti, come Windows, Linux e Mac. la tecnologia Java SE aiuta tantissimo in questo perché un jar che non si appoggia a librerie native puó girare senza modificare nulla ovunque sia installato il JRE appropriato. da quanto ho capito tu invece parli di applicazioni auto-contenute in un'unica cartella che hanno il vantaggio di poter essere portate su flash drive ed eseguite ovunque perché non richiedono un'installazione con permessi particolari (come eclipse insomma).

Se quando hai scritto le tue applicazioni desktop Java hai ravvisato la necessità insozzante è perchè non conoscevi l'alternativa. Non è che sia un delitto ma non è colpa della piattaforma.

la conoscevo eccome invece: non capisco perché tu debba dare per scontate cose che non ti sono state dette, io in passato ho avuto anche occasione di scrivere librerie native interfacciate a Java tramite JNI (una sola per la veritá, e adesso in tutta sinceritá non ricordo molto ma un'idea della complessitá mi é rimasta).

Originariamente inviato da PGI-Bis

E' un problema se un virus può scrivere nella cartella di un eseguibile in un sistema in cui ogni utente ha delle limitazioni di permesso?

dipende da che cosa ha intenzione di fare il programma con quel file; solitamente é un problema, il virus ce l'avrá anche avuto un intento nello scrivere li. un esempio molto fesso che mi viene in mente: la cartella di installazione (non scrivibile, solo leggibile/eseguibile, perdonate l'enorme approssimazione) del programma potrebbe contenere un file di licenza d'uso e se un virus lo cancellasse solamente una copia di backup della licenza potrebbe salvare i quattrini spesi dall'utente per acquistare quel software.
prima che arrivi l'obiezione: i file di licenza solitamente sono per-machine, non per-user, quindi l'esempio pur fesso calza piuttosto bene.

Diciamo che c'è un eseguibile jar non certificato: il virus lo sovrascrive e l'utente lo avvia credendo che sia l'originale.

A questo punto il virus che fa? Direi nulla più di quanto potesse fare il programma originale.

che equivale a potenziali disastri di proporzioni inimmaginabili: l'utente naturalmente ha i permessi di cancellare i suoi documenti, ti dice niente? in questo contesto potresti far perdere ad un poveraccio ore di lavoro. o forse giorni? settimane? mesi? i tempi sono dell'ordine di grandezza che vuoi tu
non credere che i virus writers di questi tempi non abbiano piu voglia di fare cose simili: abbastanza di recente mi sono alquanto divertito nel leggere di virus "usurai" che minacciavano di cancellare questo mondo e quell'altro se l'utente non avesse depositato consistenti somme di denaro su qualche conto svizzero

Forse è la condivisione delle applicazioni tra utenti con permessi diversi ad essere pericolosa più che la possibilità di scrivere nella cartella del programma.

questo naturalmente si se tu ragioni nell'ottica della difesa del sistema, ma i dati dell'utente sono molto piu importanti di file di sistema: all'utente frega poco di dover formattare o meno se i dati sono salvi sulla copia di backup.

E poi cambia qualcosa se chiudo la porta alla sovrascrittura dell'eseguibile e la lascio aperta ai plug-in che metto in application-data?

chi l'ha detto che i plug-in si mettono li? i plug-in sono programmi come tutti gli altri e vanno installati come tutti gli altri.

Originariamente inviato da malocchio

Perché mi inviti ad argomentare? E' storia che applicazioni scritte in Java siano più lente rispetto a molte altre...

ecco appunto, argomenta argomenta...

[malocchio]

Originariamente inviato da fero86

ecco appunto, argomenta argomenta...

Un'applicazione Java è oggettivamente più dispendiosa da avviare. Ovviamente molti miglioramenti sono stati fatti, e in alcuni aspetti particolari può arrivare ad essere addirittura più veloce del C++. E' comunque molto difficile confrontare Java/nativo.

Ammetto di essere vittima di un "mito"

LINK

[banryu79]

Originariamente inviato da malocchio

Un'applicazione Java è oggettivamente più dispendiosa da avviare.

A questo proposito, un articolo che illustra una strategia interessante che ho letto stamani... (ed è old, visto che è del 2005)

[PGI-Bis]

Non che wikipedia sia l'alma summa delle conoscenza ma è un buon inizio.

http://en.wikipedia.org/wiki/Portable_application

La portabilità nell'altro senso - in effetti il termine calza bene per entrambi i contesti - non la perdi per il fatto di usare una libreria dinamica. Ci sono montagne di API java che dietro le quinte fanno uso di librerie dinamiche pur essendo perfettamente multi-piattaforma.

Capita perchè la libreria dinamica dipende dalla piattaforma ma il meccanismo di risoluzione del percorso di quella libreria no.

Qui il problema è semmai se esista o non esista un omologo di APPDATA in OSX-Solaris-Linux-BSD.

[banryu79]

Originariamente inviato da PGI-Bis

Qui il problema è semmai se esista o non esista un omologo di APPDATA in OSX-Solaris-Linux-BSD.

Esattamente.
Il discorso che facevo a fero86, qualche manciata di post fa, è che lo scopo e l'esistenza di %APPDATA% è una precisa politica dei sistemi Windows.

Java non è nato per operare specificatamente su Windows, al contrario ad esempio della piattaforma .NET (tanto per avere un termine di paragone), la quale ha a disposizione, per così dire, "una base assiomatica" molto più ampia sulla quale operare...

Considerato questo, la deficienza di una apposita API nel JDK standard per il recupero di tale path non fa gridare allo scandalo...