Domino Agent struggling with Java security using third party jar in /jvm/lib/ext

问题描述:

I am running into a Java security problem. I have an agent which uses the pdfbox-1.7.1.jar to decrypt a PDF whose password I know. The jar has been placed in /jvm/lib/ext on both the server and my client, and I get this little beauty of a stack trace:

java.lang.SecurityException

at java.lang.SecurityManager.checkPermission(SecurityManager.java:582)

at COM.ibm.JEmpower.applet.AppletSecurity.checkSecurityPermission(AppletSecurity.java:1332)

at COM.ibm.JEmpower.applet.AppletSecurity.checkPermission(AppletSecurity.java:1613)

at COM.ibm.JEmpower.applet.AppletSecurity.checkPermission(AppletSecurity.java:1464)

at java.lang.SecurityManager.checkSecurityAccess(SecurityManager.java:1725)

at java.security.Security.insertProviderAt(Security.java:190)

at java.security.Security.addProvider(Security.java:210)

at org.apache.pdfbox.pdmodel.encryption.SecurityHandlersManager.getInstance(SecurityHandlersManager.java:146)

at org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1365)

at org.apache.pdfbox.pdmodel.PDDocument.decrypt(PDDocument.java:798)

at com.magerman.hremail.prep1docc.PDFDecryptor.decrypt(Unknown Source)

at com.magerman.hremail.prep1docc.MetaAttachment.decrypt(Unknown Source)

at com.magerman.hremail.prep1docc.MetaDocContainingAttachments.removePasswordOfPDFAttachments(Unknown Source)

at com.magerman.hremail.prep1docc.EPDFPreparerFactory.generateAttachmentsTriggerDocs(Unknown Source)

at com.magerman.hremail.prep1docc.EPDFPreparerFactory.run(Unknown Source)

at com.magerman.hremail.prep1docc.BaseClass.NotesMain(Unknown Source)

at lotus.domino.AgentBase.runNotes(Unknown Source)

at lotus.domino.NotesThread.run(Unknown Source)

Both Client and Server are using 8.5.3.

The Agent security level is set to 3.

Putting the jars in the agent itself does not help.

The signer of the agent is full admin on the server.

The security exception seems to point at "insertProviderAt"

This is what I tried:

putting

grant {

permission java.security.AllPermission;

}

solves my problem, but I will never get this past my eagle-eyed admin.

I am trying to reduce the scope of the permission to just the database but the documentation here: http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html did not really tell me how to input a notes database.

I looked into Stephan Wissel's article on Xpages Java security here: http://www.wissel.net/blog/d6plinks/SHWL-8JYAT5 and inserted the following into my /jvm/lib/security/java.policy file:

The solution was easier than I thought, I was confused by the reflection example.

It's a more elegant way than modifying the java.policy file (which I didn't manage, btw).

I modified the class that was creating troubles when I was calling its decrypt() method by adding a new method dopriviledgeddecrypt() which is a cunning wrapper around the method that was causing troubles. I then modified all the callers to PDFDecryptor.decrypt() so that they were calling PDFDecryptor.dopriviledgeddecrypt(). The last step involves exporting the whole class to a jar file, which is then placed in the \jvm\lib\ext folder on both the machine where you are developing (in the client) and on all the servers where this code will run.

I was also unable to find out whether there is a syntax for modifying the java.policy file so that it affects only a single Notes Database. (Update: I now know that this is not possible)