OpenPDF makes no distinctions between reading password vs editing password

Created on 1 Aug 2017 · 5Comments · Source: LibrePDF/OpenPDF

I have a PDF that is password protected for editing (PDF/A compatible PDF), but can be read without password. If you open Acrobat Reader, go to File -> Properties -> Security -> Show Details.., you can see that there are actually two passwords possible and only for editing it is enabled. Acrobat can even force the PDF to be editable without password, losing the PDF/A compatibility in the process. So either way, a password protected PDF should be viewable in OpenPDF.

OpenPDF detects that the document is encrypted, but since I don't have a password it fails the following check:

public final boolean isOpenedWithFullPermissions() {
  return !encrypted || ownerPasswordUsed;
}

I can open the PDF in other readers just fine as long as I don't enable editing mode. In OpenPDF I would expect something like the following check instead:

public final boolean isOpenedWithFullPermissions() {
  return !encrypted || ownerPasswordUsed || (!pdfRequiresReadingPassword && readonlyMode);
}

If I force this method to return true, it actually is able to read the PDF without issues (this is my current workaround, unfortunately).

bug

Source

bbottema

All 5 comments

Although not the best solution, iText works around it with a property called .unethicalreading (which I think is incorrect for PDF's that have a password for editing, not reading).

bbottema on 1 Aug 2017

Would love to see a fix for this in 1.1.1 - IMHO just adding a simple boolean flag such as allowPdfModifyWithoutOwnerPassword with getter/setter to PDFReader (and even defaulting it to true) might be the best way to handle this. I agree that "unethicalreading" is inappropriate as there is really nothing unethical about this. As I understand it, the intent of the owner password was to disallow casual modification, and not as a hard block and certainly not to disable reading entirely.