Bug 131323 - Libreoffice pdf conversion fails in FIPS mode
Summary: Libreoffice pdf conversion fails in FIPS mode
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All Linux (All)
: low normal
Assignee: Not Assigned
URL: https://www.howtogeek.com/245859/why-...
Whiteboard:
Keywords:
: 141241 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2020-03-13 07:34 UTC by aruns.suresh
Modified: 2023-04-21 19:47 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description aruns.suresh 2020-03-13 07:34:37 UTC
LibreOffice when running in an environment with FIPS enabled, pdf conversion fails with a message "Application error"


Version-Release number of selected component (if applicable):
- Libreoffice-6.4.1
- FIPS mode
- kernel 3.10.0-1062.12.1

How reproducible:


Steps to Reproduce:
1. Boot system in FIPS mode

2. Try to  convert a xls document to pdf using the command - 
libreoffice --headless --invisible --convert-to pdf sample.xls

3. Command fails with a message `Application Error`

Additional info:
- Also reproduced on LibreOffice  version 6.2.8
Comment 1 Timur 2020-03-28 08:19:50 UTC
Please explain:
1. Does GUI File-Export to PDF work? 
2. Does your sample.xls use some security/cryptography? If so, please attach.

Note for testers: To set FIPS in Windows, use the Windows Registry, go to HKLM\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\Enabled and set Enabled to 1.
Comment 2 aruns.suresh 2020-03-29 19:21:31 UTC
I never tried using the GUI File-Export to PDF. I tested this on a RedHat 7.x container.

And no, sample.xls does not use any security/cryptography.
Comment 3 Timur 2020-03-30 05:35:06 UTC
I'm not sure why FIPS would be relevant for PDF without security.
I don't reproduce in Windows. 
I can only ask you to test in some other system or wait for someone else to try this.
Comment 4 aruns.suresh 2020-03-30 17:01:33 UTC
I was able to consistently reproduce this on a REDHAT 7.x system with FIPS enabled
Comment 5 BogdanB 2020-09-16 17:39:15 UTC
Aruns, any changes about this bug?...
Comment 6 QA Administrators 2021-03-16 04:29:34 UTC Comment hidden (obsolete)
Comment 7 Timur 2021-03-25 06:17:27 UTC
*** Bug 141241 has been marked as a duplicate of this bug. ***
Comment 8 Arnab Mallik 2021-03-25 13:37:14 UTC
Similar bug has been reported in https://bugs.documentfoundation.org/show_bug.cgi?id=141241 .
Please look into it.
Comment 9 Timur 2021-03-25 15:26:20 UTC
*** Bug 141241 has been marked as a duplicate of this bug. ***
Comment 10 Shawn Bonham 2021-09-18 03:45:52 UTC
I am running into the same exact issue.  

RHEL 8.4 running FIPS mode.

Surprised there has been no movement on this for over a year.
Comment 11 Timur 2021-09-18 06:00:42 UTC
LO is volunteer driven. So bug can be resolved in a week or not resolved in a decade. You can fix it yourself, find or pay someone to get it fixed, or just wait until some dev does it, if ever.
Comment 12 Sunil 2021-12-22 10:54:37 UTC
I am also able to reproduce this error on RHEL 8.5. This bug seems to be present on LO versions > 6.0. 

Running through command line gives the following error:

> Error: Please verify input parameters... (SfxBaseModel::impl_store <file:///tmp/text.pdf> failed: 0xc10(Error Area:Io Class:Write Code:16) /home/buildslave/source/libo-core/sfx2/source/doc/sfxbasemodel.cxx:3180 /home/buildslave/source/libo-core/sfx2/source/doc/sfxbasemodel.cxx:1762)

Running Libreoffice with GUI and exporting a Writer document to PDF gives the following error:

>Error saving the document Untitled 1:
>General Error.
>General input/output error.

After searching for similar error, I came across this resolved bug for Libreoffice 5.x

https://bugzilla.redhat.com/show_bug.cgi?id=1614419

I tried installing older version of Libreoffice and seems LO 5.4 is able to export the PDF when LO 6.0 and greater seem to fail. 

Furthermore, converting a txt document to docx document succeeds. However converting any file to PDF fails with the above mentioned error. 

Anything else we can help with?
Comment 13 Timur 2022-07-06 12:23:06 UTC
Hi Caolan. Please see this bug and comment 12 indicating it's related to your commit.
Comment 14 Caolán McNamara 2022-07-20 13:39:45 UTC
NSS_NoDB_Init fails with SEC_ERROR_PKCS11_DEVICE_ERROR in HashImpl::HashImpl of comphelper/source/misc/hash.cxx. The mentioned commit of mine has (very probably) no relation to the current problem.
Comment 15 Michael.Tighe 2023-03-21 23:29:06 UTC
Timur - We are interested in fixing this issue.

Can someone show us where the code is and guide us with the process?

I just revalidated the behavior - upload a WORD document to our
application which then calls the headless LibreOffice:

"message": "Invoking Libre office call with the following command - [libreoffice --nologo --norestore --headless -env:UserInstallation=file:///work_dir/c0379a25-7ef3-43da-849

The only clue so far is :

Check exit code - true",

We might start running it on the FIPS cluster - but that's still pending.

-- Michael Tighe 
IBM.COM
Comment 16 Michael.Tighe 2023-03-22 03:06:31 UTC
I was able to run LibreOffice inside a FIPS cluster - using BASH.
The error is a complaint that it can't write the PDF file.

What should my next step be?

Here's the command:

work%% cat doit.sh
/opt/libreoffice7.3/program/soffice --nologo --norestore --headless --convert-to pdf --outdir . PP4.docx 


Here's the execution of the command: 

work%% ./doit.sh

Here's the output:

convert /var/tmp/PP4.docx -> /var/tmp/PP4.pdf using filter : writer_pdf_Export
Error: Please verify input parameters... (SfxBaseModel::impl_store <file:///var/tmp/PP4.pdf> failed: 0xc10(Error Area:Io Class:Write Code:16) /home/buildslave/source/libo-core/sfx2/source/doc/sfxbasemodel.cxx:3202 /home/buildslave/source/libo-core/sfx2/source/doc/sfxbasemodel.cxx:1775)
work%%
Comment 17 Caolán McNamara 2023-03-22 10:04:33 UTC
If I was correct back in comment #14 then run under gdb and add a breakpoint on NSS_NoDB_Init and see if that call fails and is the root of the problem.

If it is, then what the solution could be is uncertain. A custom build could experiment if --with-tls=openssl would get further
Comment 18 James Blaszkiewicz 2023-04-20 19:37:32 UTC
I was able to reproduce this issue in LibreOffice 7.3.3.2 with FIPS enabled,
>Convert /var/tmp/PP4.docx -> /var/tmp/PP4.pdf using filter : writer_pdf_Export
>Error: Please verify input parameters... (SfxBaseModel::impl_store > 
><file:///var/tmp/PP4.pdf> failed: 0xc10(Error Area:Io Class:Write Code:16) 
>/home/buildslave/source/libo-core/sfx2/source/doc/sfxbasemodel.cxx:3202 >/home/buildslave/source/libo-core/sfx2/source/doc/sfxbasemodel.cxx:1775)

I also wanted to test if it was a simple permissions issue, so I tried pointing the output path at a folder without write permissions, but with an output folder that libreoffice is unable to write to, it outputs 0x507(Error Area:Io Class:Access Code:7)) while the error we're seeing is 0xc10(Error Area:Io Class:Write Code:16), so I don't believe this is a write permissions issue. Also the only conversion that fails is to pdf.

With some research of similar issues, this 0xc10 is ERRCODE_IO_CANTWRITE which is somewhat generic, and can be set in several places. I suspect it might be on failure of creation of a temp file, but I can't be sure without either more log output from LibreOffice, or a debug run with gdb.



When testing with LibreOffice 7.5.2 in the same FIPS enabled cluster, the command was successful and the same office document was correctly converted to PDF.

Is anyone more well-versed in the code than Michael Tighe and myself able to point us in the direction of what the fix was or how to determine that?
Comment 19 Caolán McNamara 2023-04-20 20:03:06 UTC
https://wiki.documentfoundation.org/QA/Bibisect might be your friend there, git repos of pre-built binaries of libreoffice that can be used to git bisect to find the source commit range of the change.
Comment 20 James Blaszkiewicz 2023-04-21 19:47:38 UTC
With some further testing I was able to narrow the range down to: doesn't work for 7.3.3.2, does work for 7.3.4.1. So some change in 7.3.4.1 fixed this issue. 

I'll check out bibisecting to nail down the actual code changes.