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

Question

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:

grant codeBase "xspnsf://server:0/development/hre-mail/hre-mail2_0/hre-mail_(2_0)_dev.nsf/-" { 
permission java.security.AllPermission;
};

but that did not work either, I suppose because my codeBase syntax is not valid for the nsf database but only for webpages.

I am also trying to reduce the Permission to that which is really needed, and looking at the documentation here: http://docs.oracle.com/javase/1.4.2/docs/guide/security/permissions.html

implies that I have to do something like

java.security.SecurityPermission "insertProvider.{name}"

but I have no idea what {name} should be.

I also read Mikkel's article on http://lekkimworld.com/2013/06/20/java_in_notes_domino_explained_on_java_security_and_how_it_relates_to_notes_domino.html

but my brain fried at about the middle of the page. In particular, I am not sure how to actually implement this method. Could you hold my hand and walk me through please?

Whilst I'm at it, am I right in assuming that whenever I put new jars in /jvm/lib/ext, all I need to do is a

tell http restart

to have the JVM reload? I am assuming Domino is using a single JVM for Xpages, Agents, and the HTTP Task, is this right.

Also, am I right that I need to restart the server for any new policies in java.policy to be effective?

Any ideas?

Answer 1

Thanks to Richard, Simon, Mark Myers, and giulio for looking at the question.

I finally got round to understanding Mikkel's article (by reading it really slowly) on:

http://lekkimworld.com/2013/06/20/java_in_notes_domino_explained_on_java_security_and_how_it_relates_to_notes_domino.html

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)

package com.magerman.hremail.prep1docc;

public class PDFDecryptor {

/**
 * Instantiates a new pDF decryptor.
 * 
 * @param inputFile
 *            the input file
 * @param inputPassword
 *            the input password
 */
public PDFDecryptor(final File inputFile, final String inputPassword) {
originalFile = inputFile;
password = inputPassword;
}

/**
 * Decrypt. Given an inputted PDF File, will try to remove the security of
 * the PDF and save in-place. Done after the attachments have been extracted
 */
public final void decrypt() {
// naughty code here
}


public final void doproviledgeddecrypt() throws Exception {
AccessController.doPrivileged(new PrivilegedExceptionAction() {
    public Object run() throws Exception {
    PDFDecryptor.this.decrypt();
    return null;
    }
});
}

}