aboutsummaryrefslogtreecommitdiffstats
path: root/src/java/com/jogamp/common/util/PropertyAccess.java
Commit message (Collapse)AuthorAgeFilesLines
* GlueGen (Compile Time): Add 'CStruct' Annotation Processor (APT) to ↵Sven Gothel2013-06-141-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'gluegen' C Structs on-the-fly (2-pass actually). Convenient annotation processing (APT) hooked to 'javac' (1.6) via gluegen.jar META-INF service provider 'javax.annotation.processing.Processor' -> 'com.jogamp.gluegen.structgen.CStructAnnotationProcessor'. Am implicit APT / JAVAC would be possible, however - to have a proper process the unit test utilizes an explicit 2 pass run: <!-- Annotation Processor Only - First --> <javac destdir="${build_t.java}"> <classpath refid="junit.compile.classpath"/> <compilerarg value="-proc:only"/> <compilerarg value="-J-Djogamp.gluegen.structgen.debug"/> <compilerarg value="-J-Djogamp.gluegen.structgen.output=${build_t.gen}/classes"/> <src path="${test.base.dir}/com/jogamp/gluegen/test/junit/structgen"/> </javac> <!-- Javac Only - Second --> <javac destdir="${build_t.java}"> <classpath refid="junit.compile.classpath"/> <compilerarg value="-proc:none"/> <src path="${test.base.dir}"/> <src path="${build_t.gen}" /> </javac> Original code from Michael Bien's 'superglue' git://github.com/mbien/superglue.git, finally merged to GlueGen (as once intended). Note: The APT javac pass requires to use 'gluegen.jar' instead of 'gluegen-rt.jar' ! The 2-pass process also alows using the runtime gluegen-rt.jar and hence ensures clean namespace check at compilation.
* Bug 752: Review Code Vulnerabilities (Permission Checks of new exposed code ↵Sven Gothel2013-06-111-41/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix Bug 591: Fix 'jnlp.' aliasing of PropertyAccess.getProperty(..):Sven Gothel2012-06-211-17/+30
| | | | | | | | | | | | | | | | | | | Usually you set a property like jogamp.debug.IOUtil jogamp.debug=all to enable either IOUtil debugging or all debugging. In case you use Applets or JNLP you cannot use above property namespace, since it's considered insecure. GlueGen would allow you to use an 'jnlp.' alias, e.g.: jnlp.jogamp.debug.IOUtil jnlp.jogamp.debug=all The latter are secure properties and will be passed to the invoked JVM. All properties requested by PropertyAccess.getProperty(..) shall be aliased w/ 'jnlp.' (prepend 'jnlp.'), if no value could be found with the given key.
* PropertyAccess: Cleanup code, adding comment.v2.0-rc8v2.0-rc7Sven Gothel2012-04-251-7/+6
|
* PropertyAccess: Push down 'isPropertyDefined(final String property, final ↵Sven Gothel2012-03-131-5/+0
| | | | | | 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-0/+178
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'