Anomalie(s): libreoffice-7.3.4.2_1; missing lib path / signal 11 crash aft start

[F N]

Hey,

running an AMD64 XFCE4 workstation with the following settings:

1 # uname -Ki
HARDENEDBSD-13-STABLE 1301505

2 # hbsd-update -C
[+] Local version: hbsd-v1300063-6d51ca468e61bde15f12b95f282d2a2cbf0fa66f
[+] Remote version: hbsd-v1300063-6d51ca468e61bde15f12b95f282d2a2cbf0fa66f sha256 6baaad3ce14efc38644ec3416fb42ed8024e90d2d22665cf96f7513acd34feb6

On the Poudriere build host

3 # cd /usr/ports && git log -1 | grep commit
commit 1ca0018be54f3c6613ff93ceb4bc77cd918d7f04

4 # pkg info libreoffice | grep -i '^version'
Version        : 7.3.4.2_1

leads to the first anomaly while starting libreoffice in a xfce4-terminal window:

1 $ libreoffice
ld-elf.so.1: Shared object "libuno_sal.so.3" not found, required by "oosplash"

After simply inserting the missing search path for the lib with:

5 # ldconfig -m /usr/local/lib/libreoffice/program

and running libreoffice from within a xfce4-terminal again, the second anomaly occurs:

2 $ libreoffice

Fatal exception: Signal 11
Stack:
/usr/local/lib/libreoffice/program/libuno_sal.so.3+0x66336(osl_unloadUserProfile+0x676)[0x1cdb1ea2336]
/usr/local/lib/libreoffice/program/libuno_sal.so.3+0x66204(osl_unloadUserProfile+0x544)[0x1cdb1ea2204]
/lib/libthr.so.3+0x19d7e(pthread_sigmask+0x5ae)[0x1cdb1fc1d7e]
/lib/libthr.so.3+0x1923f(pthread_setschedparam+0x8bf)[0x1cdb1fc123f]
[0x7fcd59bf82d3]
/usr/local/lib/libreoffice/program/libuno_cppu.so.3+0x2064f(uno_any_clear+0x8af)[0x1cdb2f0664f]
/usr/local/lib/libreoffice/program/libuno_cppu.so.3+0x1fb70(uno_type_any_construct+0x30)[0x1cdb2f05b70]
/usr/local/lib/libreoffice/program/libutllo.so+0x7f142(_ZN3utl13ConfigManager18doStoreConfigItemsEv+0x1c2)[0x1cdb55f7142]
/usr/local/lib/libreoffice/program/libutllo.so+0x7fb46(_ZN3utl13ConfigManager11acquireTreeENSt3__117basic_string_viewIDsNS1_11char_traitsIDsEEEE+0x4e6)[0x1cdb55f7b46]
/usr/local/lib/libreoffice/program/libutllo.so+0x7321f(_ZN3utl10ConfigItemC2ERKN3rtl8OUStringE14ConfigItemMode+0x7f)[0x1cdb55eb21f]
/usr/local/lib/libreoffice/program/libutllo.so+0xbec08(_ZN26SvtSecurityMapPersonalInfo9GetInfoIDEN3rtl8OUStringE+0x26d8)[0x1cdb5636c08]
/usr/local/lib/libreoffice/program/libutllo.so+0xc0894(_ZN19SvtSysLocaleOptionsC2Ev+0xf4)[0x1cdb5638894]
/usr/local/lib/libreoffice/program/libvcllo.so+0xa123ea(_Z7InitVCLv+0x1ca)[0x1cdb62123ea]
/usr/local/lib/libreoffice/program/libvcllo.so+0xa120b1(_Z10ImplSVMainv+0x51)[0x1cdb62120b1]
/usr/local/lib/libreoffice/program/libsofficeapp.so+0x83b53(soffice_main+0x133)[0x1cdb1f3bb53]
/usr/local/lib/libreoffice/program/soffice.bin+0x1a43[0x201a43]
/usr/local/lib/libreoffice/program/soffice.bin+0x1802[0x201802]
[0x1cdb1e1d008]

The libreoffice pkg was build on the Poudriere build host with poudriere-devel-3.3.99.20220713 and default options:

 COINMP      : off
 CUPS        : on
 DOCS        : off
 GNOME       : off
 GTK3        : off
 GTK4        : off
 JAVA        : off
 KF5         : off
 LTO         : off
 MARIADB     : off
 MMEDIA      : on
 PDFIUM      : on
 PGSQL       : off
 PIE         : off
 QT5         : on
 RELRO       : on
 RETPOLINE   : on
 SAFESTACK   : off
 SDK         : off
 SLH         : off
 TEST        : off
 WEBDAV      : off

This issue is coming up regardless of setting the following hardening attributes to 1 or 2:

 sysctl hardening.pax.mprotect.status=1

 sysctl hardening.pax.pageexec.status=1
 sysctl hardening.pax.disallow_map32bit.status=1
 sysctl hardening.pax.aslr.status=1

 sysctl hardening.pax.segvguard.status=1

TPE and RTLD is left untouched from default to:

6 # sysctl -a | grep -Ei '^hardening.*(tpe|rtld)'
hardening.harden_rtld: 1
hardening.pax.tpe.user_owned: 0
hardening.pax.tpe.root_owned: 1
hardening.pax.tpe.all: 0
hardening.pax.tpe.negate: 0
hardening.pax.tpe.gid: 0
hardening.pax.tpe.status: 1

The only bug / data I found so far regarding this issue was:

 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262284

but closed because no one seems to have this case any more.

Well, the above leads me to the impression that I'm probably be a  part of the problem and missing something obvious, but sadly I can't wrap my head around it.

Any hints on how to proceed would be highly appreciated.

Regards,

Frank

[Shawn Webb]

Hey Frank,

I just barely tested this out myself. It appears RTLD hardening breaks
LibreOffice. So if you set hardening.harden_rtld=0, then LibreOffice
will work again for you.

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

[F N]

Hey Shawn,

thank you for the fast reply.

My libreoffice package still seems to have fun with me, regardless of the RTLD setting:

Within xfce root terminal on workstation :

1 # sysctl hardening.harden_rtld=0
hardening.harden_rtld: 1 -> 0

In xfce user terminal on workstation:

1 $ sysctl -a | grep '^harden.*rtld'
hardening.harden_rtld: 0

2 $ libreoffice

Fatal exception: Signal 11
Stack:

/usr/local/lib/libreoffice/program/libuno_sal.so.3+0x66336(osl_unloadUserProfile+0x676)[0x230e674f336]
/usr/local/lib/libreoffice/program/libuno_sal.so.3+0x66204(osl_unloadUserProfile+0x544)[0x230e674f204]
/lib/libthr.so.3+0x19d7e(pthread_sigmask+0x5ae)[0x230e686ed7e]
/lib/libthr.so.3+0x1923f(pthread_setschedparam+0x8bf)[0x230e686e23f]
[0x7ffb230362d3]
/usr/local/lib/libreoffice/program/libuno_cppu.so.3+0x2064f(uno_any_clear+0x8af)[0x230e77b364f]
/usr/local/lib/libreoffice/program/libuno_cppu.so.3+0x1fb70(uno_type_any_construct+0x30)[0x230e77b2b70]
/usr/local/lib/libreoffice/program/libutllo.so+0x7f142(_ZN3utl13ConfigManager18doStoreConfigItemsEv+0x1c2)[0x230e9ef9142]
/usr/local/lib/libreoffice/program/libutllo.so+0x7fb46(_ZN3utl13ConfigManager11acquireTreeENSt3__117basic_string_viewIDsNS1_11char_traitsIDsEEEE+0x4e6)[0x230e9ef9b46]
/usr/local/lib/libreoffice/program/libutllo.so+0x7321f(_ZN3utl10ConfigItemC2ERKN3rtl8OUStringE14ConfigItemMode+0x7f)[0x230e9eed21f]
/usr/local/lib/libreoffice/program/libutllo.so+0xbec08(_ZN26SvtSecurityMapPersonalInfo9GetInfoIDEN3rtl8OUStringE+0x26d8)[0x230e9f38c08]
/usr/local/lib/libreoffice/program/libutllo.so+0xc0894(_ZN19SvtSysLocaleOptionsC2Ev+0xf4)[0x230e9f3a894]
/usr/local/lib/libreoffice/program/libvcllo.so+0xa123ea(_Z7InitVCLv+0x1ca)[0x230eaa123ea]
/usr/local/lib/libreoffice/program/libvcllo.so+0xa120b1(_Z10ImplSVMainv+0x51)[0x230eaa120b1]
/usr/local/lib/libreoffice/program/libsofficeapp.so+0x83b53(soffice_main+0x133)[0x230e67e8b53]
/usr/local/lib/libreoffice/program/soffice.bin+0x1a43[0x201a43]
/usr/local/lib/libreoffice/program/soffice.bin+0x1802[0x201802]
[0x230e66ca008]
 

Am I missing something ? :-)

Regards 

[Shawn Webb]

What's the output of:

hbsdcontrol pax list /usr/local/lib/libreoffice/program/soffice.bin

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

[F N]

# hbsdcontrol pax list /usr/local/lib/libreoffice/program/soffice.bin
pageexec:          disabled
mprotect:          disabled
segvguard:         sysdef
aslr:              sysdef
shlibrandom:       sysdef
disallow_map32bit: sysdef
insecure_kmod:     sysdef

Regards

[Shawn Webb]

Off the top of my head, I'm unsure what to tell you. You might want to
look at ktrace and/or lldb. If anyone else has any ideas, feel free to
chime in.

[Frank Neuhaus]

Hey Shawn,

ok, than we know that now, thanks so far.

Going into meditation mode :-)

Regards

[F N]

As of this writing, only the Port is bumped to:

  commit 9181129303c38a62cef012482287150f13b4ca0b

and the workstation upgraded w/o any impacted packages, all other versions remain as given.

Due to the fact that I've no knowledge about lldb and currently no active experience with ktrace,
I'll start with ktrace, but it may be not correct in a 1st approach.

Unit under test in a 1st approach:

  /usr/local/lib/libreoffice/program/soffice.bin

with options given:

  --nologo
  --nosplash
  --nodefault

to minimize dependencies and unnecessary noise in kdump.

This leads to a shorter error message then before within the xfce terminal of the user:

  $ /usr/local/lib/libreoffice/program/soffice.bin --nologo --nosplash --nodefault
  Abort trap

The test environment is set up as suggested in [01], the man page of ktrace and adapted from [02] where pid is the pid of the running user shell retrieved with echo $$:

  # cd ~/tester/ktrace-LO
  # ktrace -d -i -p 94931

  $ /usr/local/lib/libreoffice/program/soffice.bin --nologo --nosplash --nodefault  

  # ktrace -C

As result, kdump leads to approx. 50.000 lines (3.0 M) of text file data.

For a 1st test specification I would suspect more missing file load ops because of the previous missing lib path in the first place
or any "unusual" messages.

So I'll get grep for this procedure and will try to find / analyze file load errors (may take some time), hoping this lead to any conclusion(s).

Any hints for a "better/smarter" or any other solution/approach will be highly appreciated.

Thanks,

Frank

---

 [01] - https://www.cyberciti.biz/tips/ktrace-freebsd-macosx-tool-howto.html

 [02] - https://www.ibm.com/support/pages/method-use-truss-non-root-user

---

[Shawn Webb]

The thing that's weird to me is that all I had to do was disable RTLD
hardening and LibreOffice worked for me.

/usr/local/bin/libreoffice is a shell script, and one of the things it
does is set LD_LIBRARY_PATH, so I wonder if you need that set if
you're going to directly execute soffice.bin.

[Loic]

The only difference I can think of is that Frank uses 13-stable, the
port of this version uses java
(commit 5d61fcf158cf00bc98dacac2625d41e7b646d528).

Franck, can you test this and give me the feedback?
# sysctl security.bsd.unprivileged_proc_debug=1
# sysctl security.bsd.allow_ptrace=1
$ mv ~/.config/libreoffice ~/.config/libreoffice_old
$ truss /usr/local/lib/libreoffice/program/soffice.bin

I can do some tests on my side at the end of the week if needed (I am
currently busy in my free time with OpenJDK in 14-CURRENT).

--
Loic
dev team
HardenedBSD

Le Mon, 18 Jul 2022 11:41:12 -0400,
Shawn Webb <shawn...@hardenedbsd.org> a écrit :

[F N]

First of all, thank you Shawn and Loic for your initiatives / ideas.

While "grepping" within kdump data, I found several file open requests referring to libs looking like gcc related libs.

That was a reminder for me about the fact that I deactivated gcc related ports within the Poudriere host
because of the openJDK anomalies some day`s before /[01]/.

After deactivating the following ports within the Poudriere ports list:

- editors/abiword
- lang/gcc
- math/gnumeric                                                
- math/suitesparse-cholmod
- math/suitesparse-config
- math/suitesparse-csparse
- math/suitesparse-cxsparse
- math/suitesparse-graphblas
- math/suitesparse-klu
- math/suitesparse-ldl
- math/suitesparse-mongoose
- math/suitesparse-rbio
- math/suitesparse-slip_lu
- math/suitesparse-spqr
- math/suitesparse-umfpack
- math/xfce4-calculator-plugin                                                                                        
- misc/xfce4-weather-plugin  
- sysutils/fusefs-lkl
- sysutils/fusefs-simple-mtpfs
- x11/xpra

the build was successful without any complains about the gcc circular dependency.

Also libreoffice was still able to start the writer and draw application,
which was considered as a major requirement then.
No other libreoffice functions where tested at this time.

Sadly I forgot to reactivate the gcc stuff again after stepping over the libreoffice signal 11 anomaly some commits later.

After reactivating the above listed ports again and updating to ports commit:

- c1a274db6bd1ab8be127ff9d4250df9fee15034a

more than 800 ports where proposed for rebuild.

This build is still running since with ETA in approx 15h ...

After the build ends I will perform the proposed tests and come back on this
matter asap.

Regards

Frank

---

[01] - E-Mail conversation: Help with OpenJDK ports;
       Mailing list HardenedBSD Users; Jul 2, 2022, 1:00 AM;
       https://groups.google.com/a/hardenedbsd.org/g/users/c/2aRwNV2_4wI

[F N]

The following scenario is now given:

 - Poudriere Build host and workstation with port:

   - commit 36322bc7c11f93efbb2da9dad90323bbf3c45010

 - # hbsd-update -C

  [+] Local version: hbsd-v1300063-6d51ca468e61bde15f12b95f282d2a2cbf0fa66f
  [+] Remote version: hbsd-v1300063-6d51ca468e61bde15f12b95f282d2a2cbf0fa66f
  sha256 6baaad3ce14efc38644ec3416fb42ed8024e90d2d22665cf96f7513acd34feb6

After re-activating the ports list to my latest known working status,
the Poudriere builds had ended without any errors.

While this is good news it took me a while to find out why the builds last so
long (approx. 3 days).

It looks like that lang/gcc (pointing to gcc11 11.3) is ALWAYS performing a
complete build with using only one cpu taking about av. 12h for a build.

Regardless of this at least new to me gcc anomaly, setting the focus to libreoffice, the following
sysctls where set as recommended by Shawn and Loic:

  # sysctl hardening.harden_rtld=0                # Shawn: RTLD
  # sysctl security.bsd.unprivileged_proc_debug=1 # Loic:  Enable truss for normal user
  # sysctl security.bsd.allow_ptrace=1            # Loic:  Enable truss for normal user

The LD_LIBRARY_PATH needed for libreoffice is expected to be set by the
libreoffice wrapper script as mentioned by Shawn.

This seems to be not the case, because the libreoffice script do not contain a
case construct for "FreeBSD".

Setting the PATH manually with:

 # ldconfig -m /usr/local/lib/libreoffice/program

seems to be sufficient for libreoffice in a 1st approach.

The setting of hbsdcontrol pax list for soffice.bin is set as recommended by Shawn.

The output of truss as requested by Loic is given in the attached file
(truss-LO_call_soffice_2022-07-22T1040_+0000_STRIPPED_HOME.txt). The real username
within this file is adjusted to "MY_USER".

Any suggestions are highly welcome.

Regards

Frank

[Loic]

On my side and like Shawn, the command "sysctl hardening.harden_rtld=0"
allows for me to run libreoffice in HBSD13.

Looking at your return from the truss order, I already see some
differences from me.

For example, "unorc" is used and there are some strange permissions
(0777):
fstatat(AT_FDCWD,"/home/MY_USER/.config/libreoffice/4/user/uno_packages/cache/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/unorc",0x762c0117bb70,AT_SYMLINK_NOFOLLOW)
ERR#2 'No such file or directory'
mkdir("/home/MY_USER/.config/libreoffice/4/user/extensions",0777) ERR#2
'No such file or directory'
mkdir("/home/MY_USER/.config/libreoffice/4/user",0777) ERR#2 'No such
file or directory' mkdir("/home/MY_USER/.config/libreoffice/4",0777)
ERR#2 'No such file or directory'
mkdir("/home/MY_USER/.config/libreoffice",0777) = 0 (0x0)
mkdir("/home/MY_USER/.config/libreoffice/4",0777) = 0 (0x0)
...
access("/usr/local/lib/libreoffice/program/unorc",F_OK) = 0 (0x0)

Out of curiosity, can you please test this:
# chmod 200 /usr/local/lib/libreoffice/program/unorc
$ soffice --safe-mode --nologo --writer

If you have a dedicated machine for powder magazine, can you build
libreoffice by deleting the line "OPTIONS_DEFAULT+= JAVA" in
"/usr/ports/libreoffice/Makefile" and test the package after the build?

Best regards,

Loic

Le Fri, 22 Jul 2022 04:08:01 -0700 (PDT),
F N <stn2...@gmail.com> a écrit :

[F N]

On Friday, July 22, 2022 at 8:57:50 PM UTC+2 loi...@hardenedbsd.org wrote:

On my side and like Shawn, the command "sysctl hardening.harden_rtld=0"
allows for me to run libreoffice in HBSD13.

Looking at your return from the truss order, I already see some
differences from me.

For example, "unorc" is used and there are some strange permissions
(0777):
fstatat(AT_FDCWD,"/home/MY_USER/.config/libreoffice/4/user/uno_packages/cache/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/unorc",0x762c0117bb70,AT_SYMLINK_NOFOLLOW)
ERR#2 'No such file or directory'
mkdir("/home/MY_USER/.config/libreoffice/4/user/extensions",0777) ERR#2
'No such file or directory'
mkdir("/home/MY_USER/.config/libreoffice/4/user",0777) ERR#2 'No such
file or directory' mkdir("/home/MY_USER/.config/libreoffice/4",0777)
ERR#2 'No such file or directory'
mkdir("/home/MY_USER/.config/libreoffice",0777) = 0 (0x0)
mkdir("/home/MY_USER/.config/libreoffice/4",0777) = 0 (0x0)
...
access("/usr/local/lib/libreoffice/program/unorc",F_OK) = 0 (0x0)

hm, looks strange indeed, have't noticed until now ...

Out of curiosity, can you please test this:
# chmod 200 /usr/local/lib/libreoffice/program/unorc

# chmod 200 /usr/local/lib/libreoffice/program/unorc
# ls -l /usr/local/lib/libreoffice/program/unorc
--w-------  1 root  wheel  239 Jul 17 16:40 /usr/local/lib/libreoffice/program/unorc
# nl /usr/local/lib/libreoffice/program/unorc
     1    [Bootstrap]
     2    URE_INTERNAL_LIB_DIR=${ORIGIN}
     3    URE_INTERNAL_JAVA_DIR=${ORIGIN}/classes
     4    URE_INTERNAL_JAVA_CLASSPATH=${URE_MORE_JAVA_TYPES}
     5    UNO_TYPES=${ORIGIN}/types.rdb ${URE_MORE_TYPES}
     6    UNO_SERVICES=${ORIGIN}/services.rdb ${URE_MORE_SERVICES}

 

$ soffice --safe-mode --nologo --writer

 

 148 $ soffice --safe-mode --nologo --writer

Fatal exception: Signal 11
Stack:

/usr/local/lib/libreoffice/program/libuno_sal.so.3+0x66336(osl_unloadUserProfile+0x676)[0x1c0a3c04336]
/usr/local/lib/libreoffice/program/libuno_sal.so.3+0x66204(osl_unloadUserProfile+0x544)[0x1c0a3c04204]
/lib/libthr.so.3+0x19d7e(pthread_sigmask+0x5ae)[0x1c0a3d23d7e]
/lib/libthr.so.3+0x1923f(pthread_setschedparam+0x8bf)[0x1c0a3d2323f]
[0x7f7efce1c2d3]
/usr/local/lib/libreoffice/program/libuno_cppu.so.3+0x2064f(uno_any_clear+0x8af)[0x1c0a4c6864f]
/usr/local/lib/libreoffice/program/libuno_cppu.so.3+0x1fb70(uno_type_any_construct+0x30)[0x1c0a4c67b70]
/usr/local/lib/libreoffice/program/libutllo.so+0x7f142(_ZN3utl13ConfigManager18doStoreConfigItemsEv+0x1c2)[0x1c0a7380142]
/usr/local/lib/libreoffice/program/libutllo.so+0x7fb46(_ZN3utl13ConfigManager11acquireTreeENSt3__117basic_string_viewIDsNS1_11char_traitsIDsEEEE+0x4e6)[0x1c0a7380b46]
/usr/local/lib/libreoffice/program/libutllo.so+0x7321f(_ZN3utl10ConfigItemC2ERKN3rtl8OUStringE14ConfigItemMode+0x7f)[0x1c0a737421f]
/usr/local/lib/libreoffice/program/libutllo.so+0xbec08(_ZN26SvtSecurityMapPersonalInfo9GetInfoIDEN3rtl8OUStringE+0x26d8)[0x1c0a73bfc08]
/usr/local/lib/libreoffice/program/libutllo.so+0xc0894(_ZN19SvtSysLocaleOptionsC2Ev+0xf4)[0x1c0a73c1894]
/usr/local/lib/libreoffice/program/libvcllo.so+0xa123ea(_Z7InitVCLv+0x1ca)[0x1c0a80123ea]
/usr/local/lib/libreoffice/program/libvcllo.so+0xa120b1(_Z10ImplSVMainv+0x51)[0x1c0a80120b1]
/usr/local/lib/libreoffice/program/libsofficeapp.so+0x83b53(soffice_main+0x133)[0x1c0a3c9db53]
/usr/local/lib/libreoffice/program/soffice.bin+0x1a43[0x201a43]
/usr/local/lib/libreoffice/program/soffice.bin+0x1802[0x201802]
[0x1c0a3b7f008]

Sadly a similar result  ...

Packages are build on a dedicated Poudriere host.

If you have a dedicated machine for powder magazine, can you build
libreoffice by deleting the line "OPTIONS_DEFAULT+= JAVA" in
"/usr/ports/libreoffice/Makefile" and test the package after the build?

 ... work in progress, will take a while, comming back asap ...

Best regards,

Best regards,

Frank

[Frank Neuhaus]

On Fri, Jul 22, 2022 at 10:02 PM F N <stn2...@gmail.com> wrote:

On Friday, July 22, 2022 at 8:57:50 PM UTC+2 loi...@hardenedbsd.org wrote:

On my side and like Shawn, the command "sysctl hardening.harden_rtld=0"
allows for me to run libreoffice in HBSD13.

Looking at your return from the truss order, I already see some
differences from me.

For example, "unorc" is used and there are some strange permissions
(0777):
fstatat(AT_FDCWD,"/home/MY_USER/.config/libreoffice/4/user/uno_packages/cache/registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/unorc",0x762c0117bb70,AT_SYMLINK_NOFOLLOW)
ERR#2 'No such file or directory'
mkdir("/home/MY_USER/.config/libreoffice/4/user/extensions",0777) ERR#2
'No such file or directory'
mkdir("/home/MY_USER/.config/libreoffice/4/user",0777) ERR#2 'No such
file or directory' mkdir("/home/MY_USER/.config/libreoffice/4",0777)
ERR#2 'No such file or directory'
mkdir("/home/MY_USER/.config/libreoffice",0777) = 0 (0x0)
mkdir("/home/MY_USER/.config/libreoffice/4",0777) = 0 (0x0)
...
access("/usr/local/lib/libreoffice/program/unorc",F_OK) = 0 (0x0)

hm, looks strange indeed, have't noticed until now ...

 

Yep, I would consider this a major non-conformity, but the process honors the current setting of 'umask' and therefore the effective file permissions written into the filesystem are adjusted to 755 for file of type directory and 644 for file of type normal, so I suppose this anomaly is intended and can be considered as harmless in a 1st approach.

The setting of the option  'JAVA' seems to have no effect on the observable outcome of the fatal exception error message of the Libreoffice package.

Also the hbsd-update is re-written with

   hbsd-update -i -b update

resulting in unchanged

  hbsd-v1300063-6d51ca468e61bde15f12b95f282d2a2cbf0fa66f sha256 6baaad3ce14efc38644ec3416fb42ed8024e90d2d22665cf96f7513acd34feb6

and Port now at

 commit 388823de219c79de364751b08a4fd3c6c26e05a2

All ports pulling in the gcc11 package are removed again from the Poudriere ports list.

The retrievable truss file with adjusted long options show still similar results with the following cmd:

  truss -o truss_out_test_LO_SIDx023-$(date '+%y%m%d%H%M.%s').txt soffice --safe-mode --nologo --nodefault --nolockcheck --nosplash --norestore --writer

Within the truss file are a lot of file load failures due to the fact that some files are finally found in an 3rd or 4th search directory but most files are found in a 1st attempt.

This "re-load" attempts might have negative impacts and I'm not sure that really the correct file versions are finally loaded.

Currently I put my focus to the following five(5) anomalies found within the truss output file:

  1) It seems to me that a kernel feature might be missing:

      __sysctlbyname("kern.features.integriforce",26,0x70a41c314f94,0x70a41c314f80,0x0,0) ERR#2 'No such file or directory'

  I'm unsure if this is really needed for Libreoffice, must or should be there? I'm currently unable to find this entry within my HBSD host so far.

  2) The symbolic links for malloc seems to be missing:

       readlink("/etc/malloc.conf",0x70a41c314730,1024) ERR#2 'No such file or directory'

 

  According to the man page this could be resolved with the following sym link   

  " ... To dump core whenever a problem occurs":

             # cd /etc

        # ln -s 'abort:true' /etc/malloc.conf

  3) + 4)  Two config files seems to be missing:

     - fstatat(AT_FDCWD,"/usr/local/lib/libreoffice/program/ooenv",0x70a41c3153f0,0x0) ERR#2 'No such file or directory'

     - access("/usr/local/lib/libreoffice/program/oosplashrc",F_OK) ERR#2 'No such file or directory'

  I've currently found no data about the intended content of this files so far. I would propose just to touch them without content.

 

  5) Libreoffice is trying to connect to a inter process communication (IPC) socket

     connect(3,{ AF_UNIX "/tmp/OSL_PIPE_1001_SingleOfficeIPC_f922462d2fa9669985943da3c9402b15" },69) ERR#2 'No such file or directory'

     

  However this socket do not exist in /tmp. The permissions for /tmp are set to default 1777, so the socket could be created but I'hv found no line creating this socket within truss.

  The filename for the IPC is not changing between different invocations of soffice.bin, Just creating a new socket leads to a connection refused message w/o valid sender/receiver.

Adjusting the host according the proposals for 2), 3) and 4) the error mesages related to this entries are goner but do not change the fatal exception error message of Libreoffice.

Further more adding a new user to the host with setting all defaults leads to the same resulting fatal exception error message of Libreoffice.

Contemplating the sentence of Loic the other day about "... the difference is 13.1 vs. 14 current ..."  leads me to the decision to perform an upgrade from 13.1 to current according to the steps given in /[HBSD-2]/ on the host.

After taking a look at the usual suspects:

- dmesg message has no strange / unusual entries

- zpool / df has suitable free space

- zpool status / scrub returned without any issues

- no strange / unneeded processes running

- beadm is properly working

- host is in isolated network with only one other outbound firewalled host

- hbsd-update is up to date

- pkg upgrade is up to date

- Poudriere build host is removed from network / system and 14/current packages are directly downloaded from hardenedbsd.org

  cutting out my Poudriere host as the "middle-man".

The upgrade from 13.1 to current was performd with minor changes to the /[HBSD-2]/ process w/o any issues noticeable.

After upgrading to current the fatal exception error message of Libreoffice survived all this and is probably having a lot of fun :-)

Now I'm confused.

Regards,

Frank

---

[HBSD-2] - https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/wikis/2%5D-Stable-To-Current

---

[Loic]

Le Sun, 24 Jul 2022 19:20:16 +0200,
Frank Neuhaus <stn2...@gmail.com> a écrit :

Usually this is normal because the software tries to adapt to the
different operating systems.

>
> Currently I put my focus to the following five(5) anomalies found
> within the truss output file:
>
> 1) It seems to me that a kernel feature might be missing:
>
>
> __sysctlbyname("kern.features.integriforce",26,0x70a41c314f94,0x70a41c314f80,0x0,0)
> ERR#2 'No such file or directory'

You can normally ignore, this is because you lack the secadm package.
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/wikis/0%5D-secadm-(English)

The problem could be here.

Can you please start HardenedBSD-CURRENT with a FreeBSD kernel to see?
# cd /tmp
# fetch -v
https://download.freebsd.org/ftp/snapshots/amd64/14.0-CURRENT/kernel.txz
# tar -zxvf kernel.txz # mv boot/kernel /boot/kernel-fbsd14

Restart and type "6" in bootloader to load this kernel. If this kernel
not work correctly, look no further, this is a hack.

LibreOffice is a huge software with millions of lines of code... The problem can be hard to identify and very varied like for example your graphics driver because of video acceleration, OpenCL etc... (you can try to use vesa or scfb for example).
Ideally, your problem should be reproducible so that we can help you
more easily because you have to understand that we are not the
developers of LibreOffice.

> Now I'm confused.
> Regards,
>
> Frank

Best regards,

Loic.

[F N]

Answers inline

Ok, thanks for reminding me about that, I stopped using  that package due to anomalies last year:

 - https://groups.google.com/a/hardenedbsd.org/g/users/c/pmlSr17_wQ0/m/rfegE5-yBAAJ

I will reinstate the secadm package asap.

This leads, after this step of extracting the kernel.txz archive, to a side-effect of the tar command.

The permissions of the /tmp file of type directory is adjusted, obviously by tar, after this step from:

  - 1777

to 

 - 0755

 

This is reproduceable with "tar -xzvf kernel.txz"  as user root on HBSD 13.1 and 14 current within the /tmp directory.

It's not clear to me wether this is a bug associated with tar or just a feature of tar at least just unknown to me.

Restart and type "6" in bootloader to load this kernel. If this kernel
not work correctly, look no further, this is a hack.

The above adjustment of the permission of /tmp from 1777 to 0755 stripping the sticky-bit and write permissions for group/others leads to really strange messages while trying to start xfce4.

After reverting to 1777 permission for /tmp, xfce4 starts w/o any complains.

Sadly, Libreoffice is in 14 current still living under the impression to just not start and provides a similar error message as given under 13.1.

Yep, I'm aware of that and the implications e.g. on quality, no doubt about it !

 

The problem can be hard to identify and very varied like for example your graphics driver because of video acceleration, OpenCL etc... (you can try to use vesa or scfb for example).

After de-activating nvidia-modeset and switching to the "vesa" driver xfce4 starts w/o any complains, but the answer of Libreoffice is the usual error message.

 

Ideally, your problem should be reproducible so that we can help you

 

Well, I know it's a bad sign that this is curently reproduceable only on this host here on the ground, I'm a bit worried about that ;-)

The feeling that I'm missing something obvious is growing steadily ...

more easily because you have to understand that we are not the
developers of LibreOffice.

Agreed, I appreaciate all the help, thoughts and initiatives very much.

  

Also updating Libreoffice with port commit e4d21b4789d27ae76a2950941cea3fe38c872b6d from

 -  7.3.4.2_1

to

  - 7.3.5.2

do not change the start anomaly of Libreoffice.

As I can see it as of now there is a lack of suitable suspects.

While thinking of the above mentioned anomaly of tar changing permissions of the parent directory above the working directory leads me to the impression that some permissions in the filesystem may not be quite correct and causing this signal 11 abort during Libreoffice start. Just a wild guess.

Best regards,

Frank

[F N]

answer inline

Meanwhile I'v done the following:

- clean installation of HBSD 14 current in a VM (within an available Proxmox cluster) on a
  simple ZFS with one drive and w/ all defaults set

- pkg update from hardenedbsd.org repository

- clean pkg installation of Xorg/XFCE4 w/ all defaults set

- cd /usr/ports && git pull as of 2022-JUL-30

- due to currently no available libreoffice pkg, new build via portmaster of libreoffice

- update to latest ports commit with:
 
  portmaster -y --no-confirm -aDvw

After all set in the new VM, Libreoffice is able to start
from the Proxmox web interface w/o any issues.

Also a x-forward via ssh to the VM from the workstation
start the Libreoffice application w/o any issues.

Which was to be demonstrated.


So, the suspect seems to be with a very high probability my workstation in two(2) versions:

- HBSD 13.1 install w/ full rebuild from my Poudriere host
  -> BUILD PROCESS INITIATED ON POUDRIERE BUILD HOST as of 2022-JUL-30
  -> hbsd-update -i -b update
  -> pkg clean
  -> pkg upgrade -f pkg
  -> pkg upgrade -f
  -> pkg upgrade -f

- HBSD 14.0 current w/ full rebuild via Port repo
  -> hbsd-update -i -b update
  -> pkg clean
  -> pkg upgrade -f pkg
  -> pkg upgrade -f
  -> pkg upgrade -f
  -> cd /usr/ports && git pull (as of 2022-JUL-30 from hardenedbsd.org)
  -> update to latest ports commit with:
     portmaster -y --no-confirm -aDvw

Workstation environment adjusted for test to:

- hardening.harden_rtld                  -> 0

- hardening.pax.mprotect.status          -> 1
- hardening.pax.pageexec.status          -> 1
- hardening.pax.disallow_map32bit.status -> 1
- hardening.pax.aslr.status              -> 1
- hardening.pax.segvguard.status         -> 1

- ldconfig -m /usr/local/lib/libreoffice/program

Currently both Libreoffice installations like to just throw an exit code 134 / signal 11.


Due to the fact that I'm able to x-forward to the VM w/ Libreoffice
from the workstation, the above workaround is a suitable concession to the given non-conformity

and I'm able to work again on related *.fodt documents.


I will now try to accomplish two(2) tasks:

 - find the root cause for this non-conformity here on the workstation
   with starting to diff the different sysctl settings, file permissions and
   truss output between the Libreoffice able VM and the workstation failing,

 - put the Libreofffice application into a jail on the HBSD workstation
   to isolate Libreoffice from the rest of the workstation as a new

   design solution for the workstation.

Due to very limited ressources on my side this will take a while and I will come back on this matter asap.

Thanks for all the input so far, though still appreciated :-)

Frank

[F N]

After applying  one of the latest updates the non-conformity described above is just gone.

At least with Poudriere running on the build host and the target X11/XFCE4 workstation with:

01 # cat /var/db/hbsd-update/version
hbsd-v1300063-d38d5ce60c46ea0be3c9118515254ebf71f61d65
02 # cd /usr/ports && git log -1 | grep commit
commit 29577ca33544d09c497f0560c1086b3e136f20ea (HEAD -> hardenedbsd/main, origin/hardenedbsd/main, origin/HEAD)

The derived package for LibreOffice compiled with:

03 $ pkg info libreoffice
libreoffice-7.5.3.2_1
Name           : libreoffice
Version        : 7.5.3.2_1
Installed on   : Wed May 17 11:25:13 2023 CEST
Origin         : editors/libreoffice
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : editors
Licenses       : MPL20 or LGPL3+
Maintainer     : off...@FreeBSD.org
WWW            : https://www.libreoffice.org/
Comment        : Full integrated office productivity suite
Options        :
CFI            : off

COINMP         : off
CUPS           : on
DOCS           : off
GNOME          : off
GTK3           : off
GTK4           : off
JAVA           : off
KF5            : off
LTO            : off
MARIADB        : off
MMEDIA         : on
PDFIUM         : on
PGSQL          : off

PIE            : on
QT5            : on
QT6            : off

RELRO          : on
RETPOLINE      : on
SAFESTACK      : off
SDK            : off
SLH            : off
TEST           : off
WEBDAV         : off

and hardening set to:

04 $ sysctl hardening
hardening.kmalloc_zero: 0
hardening.harden_tty: 1
hardening.prohibit_ptrace_syscall: 1
hardening.harden_rtld: 0
hardening.insecure_kmod: 0
hardening.procfs_harden: 1
hardening.log.ulog: 0
hardening.log.log: 1
hardening.version: 1300063
hardening.control.extattr.status: 1
hardening.control.acl.status: 1
hardening.pax.segvguard.max_crashes: 5
hardening.pax.segvguard.suspend_timeout: 600
hardening.pax.segvguard.expiry_timeout: 120
hardening.pax.segvguard.status: 2
hardening.pax.mprotect.status: 2
hardening.pax.pageexec.status: 2
hardening.pax.kmod_load_disable: 0

hardening.pax.tpe.user_owned: 0
hardening.pax.tpe.root_owned: 1
hardening.pax.tpe.all: 0
hardening.pax.tpe.negate: 0
hardening.pax.tpe.gid: 0
hardening.pax.tpe.status: 1

hardening.pax.disallow_map32bit.status: 2
hardening.pax.aslr.status: 2

LibreOffice is now running without any noticeable (at least for me) issues.

Thanks a lot to who ever introduced this change into the system.

Frank