fdo#38147 - FILESAVE File Sharing Password protected MS Word document no longer editable after reopen

Sun Jul 7 00:26:00 PDT 2013

ODT does not have a read-only protection for a document.  It has field protections and other protections.  

The LibreOffice/OpenOffice implementations add whole-document read-only protection as a setting extension.

How ODT does protections is different than how Microsoft Office does it in certain cases.  These are not easily interconverted.  In some cases, Microsoft Office protects a document in its entirety and the user specifies, before saving it, what parts are to remain editable.  

In ODF, the protections are of the reverse nature: What's protected is specified in detail and then that protection is activated.  Anything else is editable.  

(There is harmony across spreadsheets, in that protections are set at the detail level.  In addition for spreadsheets, page level protection can cover everything on a sheet regardless of settings of protection on selected parts of the sheet, and both Excel and Calc and ODF Spreadsheets all work that way.)

I cannot speak to what export and import conversion manage to accomplish, but that is the basic situation.

I assume this conversation is not about Save with Password.  That involves encryption and is a very different beast.  

 - Dennis

-----Original Message-----
From: libreoffice-bounces+orcmid=apache.org at lists.freedesktop.org [mailto:libreoffice-bounces+orcmid=apache.org at lists.freedesktop.org] On Behalf Of Thomas Arnhold
Sent: Saturday, July 6, 2013 09:52 PM
To: libreoffice
Cc: Michael Stahl; Cédric Bosdonnat
Subject: fdo#38147 - FILESAVE File Sharing Password protected MS Word document no longer editable after reopen

Hi,

I've somehow investigated the problem with password protected Word 
documents. It was marked as Hard Hack. I have to admit, that I don't 
know any further and someone else with more background on form 
protection has to look into this.

I've attached "fix.patch" which only shows where the difference between 
both file formats begins. "0001-debug.patch" is my debug information.

Here's some of the mail correspondence with mst:

--- snip ---

I compared the behavior of odt and doc files. The difference is at:
http://opengrok.libreoffice.org/xref/core/sw/source/core/crsr/pam.cxx#724

IDocumentSettingAccess::PROTECT_FORM is always 0 for odt files. And 1 
for doc files. This seems strange, I expected that odt files have this 
flag too. So odt has no (proper?) form protection as I understand this. 
I added two files to the bug, which demonstrate, that odt has no form 
protection (I could click the button and the checkbox).

This code block in pam.cxx had a comment in history:
"TODO: Form Protection when Enhanced Fields are enabled"

What are "Enhanced Fields"? Are this forms?

Nevertheless if I comment that block out (see patch) the problem is 
fixed. The doc file can be unlocked, edited and saved properly. But I 
don't know what the deeper consequences are ;)

--- snap ---

--- snip ---

On 18.04.2013 13:05, Michael Stahl wrote:
 >> IDocumentSettingAccess::PROTECT_FORM is always 0 for odt files. And 1
 >> for doc files. This seems strange, I expected that odt files have this
 >> flag too. So odt has no (proper?) form protection as I understand this.
 >> I added two files to the bug, which demonstrate, that odt has no form
 >> protection (I could click the button and the checkbox).
 >
 > apparently this is available at SwXDocumentSettings as "ProtectForm"
 > property and should also be stored into/loaded from ODF files (in a
 > generic way).  but the only way for it to be enabled is apparently
 > loading an WW8 file.  i assume if you load a WW8 file with it enabled,
 > store it as ODF and load again it should be on?

Yes you are right, if I store the ww8 file as odf and load it again the 
form protection mode is on.

 >> This code block in pam.cxx had a comment in history:
 >> "TODO: Form Protection when Enhanced Fields are enabled"
 >>
 >> What are "Enhanced Fields"? Are this forms?
 >
 > "ordinary" fields in Writer contain just an unformatted string of text,
 > and are represented by a single dummy character in the paragraph text.
 >
 > the "enhanced" ones however are implemented totally differently, with a
 > special kind of bookmark and dummy 0x04 or so characters in the text to
 > mark the start/end positions.  the content of an enhanced field is
 > arbitrary paragraph content with arbitrary formatting.
 >
 >> Nevertheless if I comment that block out (see patch) the problem is
 >> fixed. The doc file can be unlocked, edited and saved properly. But I
 >> don't know what the deeper consequences are ;)
 >
 > i don't think that is such a good idea.  perhaps there should be some
 > way to enable this setting for newly created documents, but i don't know
 > how it is possible to create the enhanced fields from the UI... has that
 > ever been implemented?   can we just load them from WW8 and ODF
 > (extended) files?

I've got some closer to the problem.

https://bugs.freedesktop.org/attachment.cgi?id=48023
( password: 1111 )

->bProtectForm:0
-> can be edited and saved in the first iteration

after closing and reloading this is not possible to edit anymore. the 
error described in the bug report pops up.
->bProtectForm:1

https://bugs.freedesktop.org/show_bug.cgi?id=43229

seems to be already saved by libreoffice, because the error pops up by 
default.

-> loads with
->bProtectForm:1

Where is the problem? It's at: sw/source/filter/ww8/wrtww8.cxx WriteDop()

rDop.lKeyProtDoc is set to a value so the form protection mode get's 
enabled while saving this file. If you load this file again it will now 
have the form protection mode enabled. This additional check for 
lKeyProtDoc came in with 2559ef0f64b7a9a593d60edfcc8107f3a13ee5e1 in 2010.

This fProtEnabled will bes PROTECT_FORM to true at 
sw/source/filter/ww8/ww8par.cxx ImportDop().

If this is really the root of the problem all ww8 documents with enabled 
protection which were opened/edited and saved since then will have this 
form protection flag enabled and are not editable...

--- snap ---

Hopefully this will get fixed sometime :)

Thomas