[
https://issues.apache.org/jira/browse/PDFBOX-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156690#comment-14156690
]
Tilman Hausherr commented on PDFBOX-2397:
-----------------------------------------
You're probably right, but I need to understand this topic before I make a
change. I've read a bit on it on the web, e.g. at
https://stackoverflow.com/questions/2233761/when-should-accesscontroller-doprivileged-be-used
but I don't get it. Lets say I'm an newbie NSA contractor, and my job is to
write an evil applet that masks as a java applet game, but truly reads the
content of "C:\users" and then plan further intrusive misdeeds. Articles found
on google claim that all I have to do is to call
AccessController.doPrivileged(), or so it seemed to me. The call to new
File("/").listFiles() will throw a security exception in an ordinary applet. So
I write this code and now I have the information:
{code}
File[] flist = (File[]) AccessController.doPrivileged(new PrivilegedAction()
{
public Object run()
{
return new File("/").listFiles();
}
});
{code}
Whats the flaw in my logic?
Or is AccessController.doPrivileged() needed WHEN a permission is enabled, i.e.
SecurityException would still be thrown even if the needed permission is
enabled AND the call is made outside of AccessController.doPrivileged() ? I.e.
that with the current PDFBox version, you wouldn't be able to set
org.apache.pdfbox.ICC_override_color even if your applet is signed and has the
permission enabled?
Is this the code that you'd like?
{code}
private static volatile Color iccOverrideColor = null;
static
{
try
{
AccessController.doPrivileged(new PrivilegedAction()
{
public Object run()
{
iccOverrideColor =
Color.getColor("org.apache.pdfbox.ICC_override_color");
return null;
}
});
}
catch (Exception e)
{
}
}
{code}
> Running within an Applet throws an AccessControlException
> ---------------------------------------------------------
>
> Key: PDFBOX-2397
> URL: https://issues.apache.org/jira/browse/PDFBOX-2397
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
> Affects Versions: 1.8.7
> Environment: JRE 7u67 or JRE 6u45 (Windows 7 SP1 64bit)
> Reporter: Bertrand GILLIS
> Assignee: Tilman Hausherr
> Fix For: 1.8.8
>
>
> As soon as PDFBox is embedded in a signed applet, the following exception is
> thrown when I try to print a PDF document through PDFBox:
> {code}
> Caused by: java.security.AccessControlException: access denied
> ("java.util.PropertyPermission" "org.apache.pdfbox.ICC_override_color" "read")
> at java.security.AccessControlContext.checkPermission(Unknown Source)
> at java.security.AccessController.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkPermission(Unknown Source)
> at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown
> Source)
> at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
> at java.lang.System.getProperty(Unknown Source)
> at java.lang.Integer.getInteger(Unknown Source)
> at java.lang.Integer.getInteger(Unknown Source)
> at java.awt.Color.getColor(Unknown Source)
> at java.awt.Color.getColor(Unknown Source)
> at
> org.apache.pdfbox.pdmodel.graphics.color.PDColorState.<clinit>(PDColorState.java:50)
> {code}
> This issue was also in previous PDFBox versions for the following instruction:
> {code:title=BaseParser.java}
> FORCE_PARSING = Boolean.getBoolean("org.apache.pdfbox.forceParsing");
> {code}
> But it was fixed in later versions:
> {code:title=BaseParser.java}
> static {
> try {
> FORCE_PARSING = Boolean.getBoolean("org.apache.pdfbox.forceParsing");
> }
> catch (SecurityException e) {}
> }
> {code}
> This fixed is unfortunately not set for the current property:
> {code:title=PDColorState.java}
> private static volatile Color iccOverrideColor =
> Color.getColor("org.apache.pdfbox.ICC_override_color");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
