Come disabilitare il gestore della sicurezza Java?

Question

Esiste un modo per disattivare completamente il gestore della sicurezza Java?

Sto sperimentando con il codice sorgente di db4o. Usa la riflessione per mantenere gli oggetti e sembra che il responsabile della sicurezza non permetta la riflessione per leggere e scrivere campi privati ​​o protetti.

Il mio codice:

public static void main(String[] args) throws IOException { 
    System.out.println("start"); 
    new File(DB_FILE_NAME).delete(); 
    ObjectContainer container = Db4o.openFile(DB_FILE_NAME); 
    String ob = new String("test"); 
    container.store(ob); 
    ObjectSet result = container.queryByExample(String.class); 
    System.out.println("retrieved (" + result.size() + "):"); 
    while(result.hasNext()) { 
     System.out.println(result.next()); 
    } 
    container.close(); 
    System.out.println("finish"); 
} 

uscita:

 
start 
[db4o 7.4.68.12069 2009-04-18 00:21:30] 
AccessibleObject#setAccessible() is not available. Private fields can not be stored. 
retrieved (0): 
finish 

This thread suggerisce la modifica di file java.policy per consentire riflessione, ma non sembra funzionare per me. JVM

Sto iniziando con argomenti
-Djava.security.manager -Djava.security.policy==/home/pablo/.java.policy
file dei criteri in modo specificato sarà l'unico file dei criteri utilizzati

Il file è simile al seguente:

 
grant { 
    permission java.security.AllPermission; 
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; 
}; 

ho trascorso gli ultimi 3 ore su questo e non hai idee su come fare questo lavoro. Qualsiasi aiuto apprezzato.

Answer 1

Hai davvero due segni "=" nella tua opzione da riga di comando java.security.policy? Quello non funzionerà. Assicurarsi che si sta impostando la proprietà come

-Djava.security.policy=/home/pablo/.java.policy 

Per disabilitare in realtà il SecurityManager, semplicemente lasciando fuori la proprietà di sistema java.security.manager tutto dovrebbe essere sufficiente.

---

Aggiornamento: Mentre leggevo la documentazione per i file di criteri di conoscere meglio il "==" sintassi, ho notato che a meno che il file di criteri si trova nella directory di lavoro corrente, deve essere specificato come URL (incluso lo schema). Hai provato a prefixare il percorso del criterio con lo schema "file:"?

Sono rimasto perplesso perché (supponendo che tu stia eseguendo come utente "pablo"), sembra che tale politica debba essere caricata di default dalla tua home directory, quindi non dovresti specificarla affatto. D'altra parte, se non si esegue l'utente "pablo", forse il file non è leggibile.

Answer 2

Si potrebbe provare ad aggiungere questo al main() del programma:

System.setSecurityManager(null); 

lavorato per me per un'applicazione WebStart "trusted" quando stavo avendo problemi di Security Manager. Non sono sicuro se funzionerà per il tuo caso db4o, ma potrebbe valere la pena provare.

EDIT: Non sto suggerendo che questa sia una soluzione generale ai problemi del gestore della sicurezza. Stavo solo proponendolo come un modo per aiutare a risolvere il problema del poster originale. Chiaramente, se vuoi beneficiare di un gestore della sicurezza, non dovresti disabilitarlo.

Answer 3

Ho trovato questo esempio di come make private fields and methods accessible al codice. Fondamentalmente, si distilla fino all'uso del campo .setAccessible (vero) e Method.setAccessible (vero) esempio

campo:

Field privateStringField = PrivateObject.class. 
      getDeclaredField("privateString"); 

privateStringField.setAccessible(true); 

Metodo esempio:

Method privateStringMethod = PrivateObject.class. 
     getDeclaredMethod("getPrivateString", null); 

privateStringMethod.setAccessible(true); 

Si potrebbe anche guardare con Groovy con il codice Java come (attualmente) elude gran parte delle restrizioni del livello di accesso del codice Java. Anche se questa pubblicazione di messaggi sembra suggerire questa 'funzione' may change in future versions of Groovy.