summaryrefslogtreecommitdiffstats
path: root/src/java/jogamp/common/Debug.java
Commit message (Collapse)AuthorAgeFilesLines
* gluegen: add all missing @Override annotationsHarvey Harrison2013-10-171-0/+1
| | | | Signed-off-by: Harvey Harrison <[email protected]>
* gluegen: remove trailing whitespaceHarvey Harrison2013-10-171-8/+8
| | | | Signed-off-by: Harvey Harrison <[email protected]>
* Remedy for Bug 782: Issue Debug.initSingleton() or Debug.debug(..) before ↵Sven Gothel2013-07-171-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | calling 'PropertyAccess.isPropertyDefined(propName, default)' through Debug class. Calling 'Debug.isPropertyDefined(propName, default)' may be 'optimized' to 'PropertyAccess.isPropertyDefined(propName, default)', which would skip the modules Debug's class initialization. Iff that happens, an AccessControlException may happen, due to requesting an insecure property, since modules own Debug class has not been added it's trusted prefixes from within it's init block yet. This seems to be a bug of the JVM .. to me, however .. the above description is the only able to explain the issue at hand. +++ Fix calls Debug class own static methods, either Debug.initSingleton() or Debug.debug(), before calling 'isPropertyDefined(propName, default)'. +++ Also mark Debug class static methods final! +++
* Bug 752: Review Code Vulnerabilities (Permission Checks of new exposed code ↵Sven Gothel2013-06-111-18/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and privileged access) This review focuses on how we perform permission checks, or better - do we circumvent some assuming full privileges ? Some native methods do need extra permission validation, i.e. loading native libraries. Further more AccessController.doPrivileged(..) shall not cover generic code exposing a critical feature to the user. Further more .. we should rely on the SecuritManager, i.e. AccessControlContext's 'checkPermission(Permission)' code to comply w/ fine grained permission access. It is also possible to have full permission w/o having any certificates (-> policy file). +++ We remove implicit AccessController.doPrivileged(..) from within our trusted code for generic methods, like Property access, temp. files. +++ SecurityUtil: - Remove 'getCommonAccessControlContext(Class<?> clz)', which returned a local AccessControlContext for later restriction if the passed class contains all certificates as the 'trusted' GlueGen class has. - Simply expose convenient permission check methods relying on SecurityManager / AccessControlContext. PropertyAccess: - 'protected static void addTrustedPrefix(..)' requires AllPermissions if SecurityManager is installed. - Remove implicit doPrivileged(..) triggered by passed AccessControlContext instance, only leave it for trusted prefixes. IOUtil: - Remove all doPrivileged(..) - Elevation shall be performed by caller. DynamicLinker: - 'public long openLibraryLocal(..)' and 'public long openLibraryGlobal(..)' may throw SecurityException, if a SecurityManager is installed and the dyn. link permission is not granted in the calling code. Implemented in their respective Unix, OSX and Windows manifestation. Caller has to elevate privileges via 'doPrivileged(..) {}' ! +++ Tests: - Property access - File access - Native library loading Manual Applet test (unsigned, but w/ SecurityManager and policy file): > gluegen/test/applet Applet has been tested w/ signed JAR w/ Firefox and Java7 on GNU/Linux as well. Manual Application test (unsigned, but w/ SecurityManager and policy file): com.jogamp.junit.sec.TestSecIOUtil01 - Run w/ SecurityManager and policy file: - gluegen/scripts/runtest-secmgr.sh - Run w/o SecurityManager: - gluegen/scripts/runtest.sh
* PropertyAccess: Push down 'isPropertyDefined(final String property, final ↵Sven Gothel2012-03-131-0/+4
| | | | | | boolean jnlpAlias)' for trusted properties The method shall be called by the respective Debug specialization, which registers the trusted property prefix.
* SecurityUtil: Generalize cert validation and AccessControlContext query; ↵Sven Gothel2012-03-131-18/+14
| | | | | | | | | | | | | | | | | | PropertyAccess: Fix security code, grant access to common 'trusted' properties - SecurityUtil - Generalize cert validation for JAR and property access - Grant access to common AccessControlContext for 'same' cert - PropertyAccess: - Fix security code: Passing the current AccessControlContext from the caller didn't include priviledges. - Grant access to common 'trusted' properties, which removes the need of passing the AccessControlContext for general properties like 'jnlp.', 'jogamp.' .. - Enable registering 'trusted' properties, when caller's cert is 'same'
* Intro.: PropertyAccess ; Added safe PropertyAccess for JNILibLoaderBase, ↵Sven Gothel2012-03-131-72/+1
| | | | | | | | | | | | | | | | | Platform, IOUtil, .. - Intro.: PropertyAccess - Base class of all Debug impl, reduces redundancies. - jnlpAlias'ed trusted property is queried within local AccessControlContext to avoid 'JRE' implementation differences (should not be required). - throw NPE and IllegalArgumentException for invalid property key - Added safe PropertyAccess - JNILibLoaderBase: sun.jnlp.applet.launcher - Platform: jogamp.gluegen.UseTempJarCache - IOUtil: java.io.tmpdir
* Add boolean system property 'jogamp.gluegen.UseTempJarCache', defaults to ↵Sven Gothel2011-09-231-4/+11
| | | | 'true' - allowing to disable usage of TempJarCache.
* Move implementation private files from com.jogamp.<module>.impl. to ↵Sven Gothel2011-02-091-0/+149
jogamp.<module> - com.jogamp.common.impl -> jogamp.common This sorts implementation details from the top level, ie skipping the public 'com', allowing a better seperation of public classes and implementation details and also reduces strings. This approach of public/private seperation is also used in the OpenJDK.