System.loadLibrary() rifiuta di caricare "librerie" con il separatore di percorso che appare nel nome; guarda questo estratto dal codice sorgente di Java (in java.lang.Runtime.java ):
synchronized void loadLibrary0(Class fromClass, String libname) {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkLink(libname);
}
if (libname.indexOf((int)File.separatorChar) != -1) {
throw new UnsatisfiedLinkError(
"Directory separator should not appear in library name: " + libname);
}
ClassLoader.loadLibrary(fromClass, libname, false);
}
Come tale, potresti immaginare ammettere System.loadLibrary() ma rifiutare System.load() , dando accesso solo a un set specifico di librerie "sicure" caricabili ... tuttavia, ciò sembra indiretto e fragile. Il modo "normale" di limitare il caricamento del codice nativo è attraverso SystemManager.checkLink () , che viene chiamato sia da System.load() sia da System.loadLibrary() . In tal caso, non vi è alcuna reale differenza di sicurezza tra i due metodi.
Affidarsi al sistema di chiamata per aiutare a localizzare le cose può sicuramente portare a percorsi inusuali. Il problema più grande è che il sistema può fornire un file che non è stato progettato per essere caricato dall'applicazione. Se un utente malintenzionato può inserire un file in una posizione che rientra nella ricerca, l'utente malintenzionato può inserire codice arbitrario nell'applicazione ed eseguirlo. Per esempio. vulnerabilità di esecuzione di codice arbitrario ( collegamento ).
Se specifichi il percorso esatto, hai la possibilità di proteggere il file caricato attraverso cose come permessi di file, ecc.