Using LibreOffice results in many AppArmor audit log messages marked as "ALLOWED".
These messages repeat many times during normal use of the app, resulting in
quite a bit of log spam.

Perhaps this is the result of the user's home directory being mounted in an alternate location?

A small sampling of messages (obfuscated):

May  1 17:19:49 host kernel: [ 9201.656675] audit: type=1400 audit(1588371589.713:822): apparmor="ALLOWED" operation="mknod" profile="libreoffice-soffice" name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 comm="configmgrWriter" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
May  1 17:19:49 host kernel: [ 9201.657039] audit: type=1400 audit(1588371589.713:823): apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 comm="configmgrWriter" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
May  1 17:19:49 host kernel: [ 9201.657107] audit: type=1400 audit(1588371589.717:824): apparmor="ALLOWED" operation="file_lock" profile="libreoffice-soffice" name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 comm="configmgrWriter" requested_mask="wk" denied_mask="wk" fsuid=1000 ouid=1000
May  1 17:19:49 host kernel: [ 9201.670903] audit: type=1400 audit(1588371589.729:825): apparmor="ALLOWED" operation="rename_src" profile="libreoffice-soffice" name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 comm="configmgrWriter" requested_mask="wrd" denied_mask="wrd" fsuid=1000 ouid=1000
May  1 17:19:49 host kernel: [ 9201.670926] audit: type=1400 audit(1588371589.729:826): apparmor="ALLOWED" operation="rename_dest" profile="libreoffice-soffice" name="/raid/home/user/.config/libreoffice/4/user/registrymodifications.xcu" pid=16453 comm="configmgrWriter" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000

retitle 959399 libreoffice-common: many AppArmor "ALLOWED" log messages
if using "non-standard" $HOME
severity 959399 minor
tag 959399 + wontfix
thanks

Yes, and to be honest, if you change that dir you need to change all
profiles referencing $HOME to allow it.

Here you can be just glad it works because the profile is in complain
mode, if it wasn't this wouldn't work at all...

One simply cannot allow any path as this would simply defeat the
purpose.

why /raid as extra mountpoint and not /home directly or / directly or if
that's not intended some bind mounts to have /home on a "known"
location? So that stuff like this doesn't knowingly break?
Or is that the case?

I am honestly not sure whether there's something to do there at all -
except for the admin of the system to adapt the profile to the setuo of
the system.

Regards,

Rene

Hi again.

And what is your @HOME set for in apparmor sense?

  owner @{HOME}/.config/libreoffice{,dev}/** rwk,

is in the profile, which allows the owner of the config dir in @{HOME}
access.

So I just bet that setting needs to be globally adapted
for apparmor?
(Or use standard paths.)

Regards,

Rene

I guess I don't understand what needs to be changed.  $HOME is /home, which
is where the local users homes are.  There are additional mount points
(/raid, and one other) that hold additional network mounts of remotely store
users' home directories.

How should the configuration be changed for multiple home directories being
stored and mounted in multiple locations?

Evan

Hi,

No, $HOME isn't. $HOME in your case is "/raid/home/user/.

But you run as a remote user?

name="/raid/home/user/.config/libreoffice/4/user/GpDXp7

suggests so.

Erm, what?

I mentioned

@{libo_user_dirs} = @{HOME} /mnt /media

Wouldn't be surprised if @{HOME} (documented as "all homedirs") actually
means /home/** and thus wouldn't allow /raid/home/**.

I'd first try adding /raid/home there, obviously?

Regards,

Rene

Actually it's not.  In the particular example I gave logs for, $HOME is
/home/user.  It just happens that /home is a symlink to /raid/home.

I don't know where that is configured.  Where would I find that?

Where is "there"?

Aha...

This is cut'n'paste the libreoffice (well
/usr/lib/libreoffice/program/soffice.bin) apparmor profile.

(/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin)

BTW: This is not a apparmor or configuration support, this is for
tracking bugs ;-)

Regards,

Rene

Dear submitter,

as the package libreoffice has just been removed from the Debian archive
experimental we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1069123

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Humanitarian Grant of 1.5M for you. Reply for claims

Hi,

Am 01.09.25 um 20:50 schrieb Michael Hierweck:
 >
 > Indeed.

Thanks for confirming.

 > I purged(!) and reinstalled all LibreOffice-Packages now.

Yeah, you need purge since it's a conffile...
(A Shortcut would have been to rm the profiles and do a dpkg -i --force-confmiss on libreoffice-common after downloading it manually - or from /var/cache/apt/archives if still there :) )

 > I noticed that apparmor_parser runs forever (triggered by the libreoffice-common postinstall script) when both "/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin" is present *and* the debconf variable "apparmor/homedirs" contains "/home/users/".
 >
 > The profiles are processed in less than 15secs when setting this variable to "/foo/bar/". (Or even when replacing "/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin" with an empty file.)
 >

 > If "/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin" is replaced with an empty file and the AppArmor cache is regenerated, LibreOffice can be started by calling the nice normal start script (/usr/bin/libreoffice).

As expected.

Yes, no one denied that given all the bugs and that it's unmaintained. (Which are not an issue per se if it's complain, except the logging...)

And as we notice (and #959399 noticed) problems when $HOME is non-standard in /home :)

No problem, I just wonder what to do with this... ;)


CC'ing #959399 at least since it has the same root cause. Wondering whether they should be merged...

Regards,


Rene

Hi,

Am 01.09.25 um 20:50 schrieb Michael Hierweck:
 >
 > Indeed.

Thanks for confirming.

 > I purged(!) and reinstalled all LibreOffice-Packages now.

Yeah, you need purge since it's a conffile...
(A Shortcut would have been to rm the profiles and do a dpkg -i --force-confmiss on libreoffice-common after downloading it manually - or from /var/cache/apt/archives if still there :) )

 > I noticed that apparmor_parser runs forever (triggered by the libreoffice-common postinstall script) when both "/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin" is present *and* the debconf variable "apparmor/homedirs" contains "/home/users/".
 >
 > The profiles are processed in less than 15secs when setting this variable to "/foo/bar/". (Or even when replacing "/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin" with an empty file.)
 >

 > If "/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin" is replaced with an empty file and the AppArmor cache is regenerated, LibreOffice can be started by calling the nice normal start script (/usr/bin/libreoffice).

As expected.

Yes, no one denied that given all the bugs and that it's unmaintained. (Which are not an issue per se if it's complain, except the logging...)

And as we notice (and #959399 noticed) problems when $HOME is non-standard in /home :)

No problem, I just wonder what to do with this... ;)


CC'ing #959399 at least since it has the same root cause. Wondering whether they should be merged...

Regards,


Rene

Hi,

After installing the recent Upgrade (13.0 -> 13.1) my workaround (empty
/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin) refuses to work.

I cleanedup the configuration again:

# rm $(cat /var/lib/dpkg/info/libreoffice-common.conffiles)
# dpkg -i --force-confmiss /var/cache/apt/archives/libreoffice-common_4%3a25.2.3-2+deb13u2_all.deb

This makes apparmor_parer run forever while the package is configured.

# rm $(cat /var/lib/dpkg/info/libreoffice-common.conffiles)
# touch /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin
# dpkg -i --force-confmiss /var/cache/apt/archives/libreoffice-common_4%3a25.2.3-2+deb13u2_all.deb

This solve the issue mentioned above but libreoffice refuses to start.

Message: "ERROR 4 forking process"
Caused by: /usr/lib/libreoffice/program/oosplash

I still wonder why this is related to AppArmor because oosplash is in complain mode only.

# aa-status |egrep "^[0-9]|libre|oosplash|soffice"
176 profiles are loaded.
54 profiles are in enforce mode.
    libreoffice-senddoc
    libreoffice-xpdfimport
46 profiles are in complain mode.
    libreoffice-oosplash
0 profiles are in prompt mode.
0 profiles are in kill mode.
76 profiles are in unconfined mode.
35 processes have profiles defined.
7 processes are in enforce mode.
5 processes are in complain mode.
0 processes are in prompt mode.
0 processes are in kill mode.
23 processes are unconfined but have a profile defined.
0 processes are in mixed mode.

Regards,

Michael

Hi,

After installing the recent Upgrade (13.0 -> 13.1) my workaround (empty
/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin) refuses to work.

I cleanedup the configuration again:

# rm $(cat /var/lib/dpkg/info/libreoffice-common.conffiles)
# dpkg -i --force-confmiss /var/cache/apt/archives/libreoffice-common_4%3a25.2.3-2+deb13u2_all.deb

This makes apparmor_parer run forever while the package is configured.

# rm $(cat /var/lib/dpkg/info/libreoffice-common.conffiles)
# touch /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin
# dpkg -i --force-confmiss /var/cache/apt/archives/libreoffice-common_4%3a25.2.3-2+deb13u2_all.deb

This solve the issue mentioned above but libreoffice refuses to start.

Message: "ERROR 4 forking process"
Caused by: /usr/lib/libreoffice/program/oosplash

I still wonder why this is related to AppArmor because oosplash is in complain mode only.

# aa-status |egrep "^[0-9]|libre|oosplash|soffice"
176 profiles are loaded.
54 profiles are in enforce mode.
    libreoffice-senddoc
    libreoffice-xpdfimport
46 profiles are in complain mode.
    libreoffice-oosplash
0 profiles are in prompt mode.
0 profiles are in kill mode.
76 profiles are in unconfined mode.
35 processes have profiles defined.
7 processes are in enforce mode.
5 processes are in complain mode.
0 processes are in prompt mode.
0 processes are in kill mode.
23 processes are unconfined but have a profile defined.
0 processes are in mixed mode.

Regards,

Michael

Dear maintainer,

I believe I'm running into the same issue.
In `/etc/apparmor.d/tunables/home.d/site.local` I have `@{HOMEDIRS}+=/homes/` (This is a historical artefact, but I'm very much stuck with it).
The result is that `service apparmor reload` fails, because of the profile in `/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin`. In isolation this can be shown with `apparmor_parser --replace -Qv /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin`, which would eat a CPU and chug along for a minute or two before failing with `Too many states (98514) for type state_t`.
Truncating the profile resolves these symptoms, and will be my workaround for the time being.

Kind regards,
Peter Kroon

Hi,

That one is now upstream since some time.

The profile has a

@{libo_inst_dir} = @INSTDIR@

@{libo_user_dirs} = @{HOME} /mnt /media

which might mean the discussion in https://gerrit.libreoffice.org/c/core/+/190686/comments/90fcd4d9_158418fb aka
"#959399: This one's easy: AppArmor has a @{HOMEDIRS} tunable that exists for this very purpose. On Debian-based systems, all you need to do is dpkg-reconfigure apparmor and set it up appropriately."
should now work.

This is only in 26.2.0 alph1, though, which is uploaded to experimental (on the way to NEW unfortunately) but also available at https://people.debian.org/~rene/libreoffice/26.2/.[1]

If you have a system on which you can try the stuff from xperimental (which needs stuff from sid, of course, too, so best do it in a sid environment...) it would be helpful.

Regards,

Rene

[1] deb [signed-by=/usr/share/keyrings/debian-keyring.gpg] http://people.debian.org/~rene/libreoffice/26.2 ./
     (and install debian-keyring. Or or use [trusted=yes]...)

Hi,

That one is now upstream since some time.

The profile has a

@{libo_inst_dir} = @INSTDIR@

@{libo_user_dirs} = @{HOME} /mnt /media

which might mean the discussion in https://gerrit.libreoffice.org/c/core/+/190686/comments/90fcd4d9_158418fb aka
"#959399: This one's easy: AppArmor has a @{HOMEDIRS} tunable that exists for this very purpose. On Debian-based systems, all you need to do is dpkg-reconfigure apparmor and set it up appropriately."
should now work.

This is only in 26.2.0 alph1, though, which is uploaded to experimental (on the way to NEW unfortunately) but also available at https://people.debian.org/~rene/libreoffice/26.2/.[1]

If you have a system on which you can try the stuff from xperimental (which needs stuff from sid, of course, too, so best do it in a sid environment...) it would be helpful.

Regards,

Rene

[1] deb [signed-by=/usr/share/keyrings/debian-keyring.gpg] http://people.debian.org/~rene/libreoffice/26.2 ./
     (and install debian-keyring. Or or use [trusted=yes]...)

Hi,

Am 22.11.25 um 09:40 schrieb Rene Engelhard:

https://people.debian.org/~rene/libreoffice/26.2/my.repo

(in a better-named file ;)) in sources.list.d

Either as-s with the key included or with

Signed-By: /usr/share/keyrings/debian-keyring.gpg

for which you would need to install debian-keyring, as said.

Regards,

Rene

Hi,

Am 22.11.25 um 09:40 schrieb Rene Engelhard:

https://people.debian.org/~rene/libreoffice/26.2/my.repo

(in a better-named file ;)) in sources.list.d

Either as-s with the key included or with

Signed-By: /usr/share/keyrings/debian-keyring.gpg

for which you would need to install debian-keyring, as said.

Regards,

Rene

Dear maintainer,

apologies for the late reply. Holidays, life, and the day job :)
Returning from holidays I found that libreoffice failed to start with a truncated apparmor profile, but works as intended (and expected) after purging and reinstalling libreoffice-common version 25.2.3-1+deb. For reference, apparmor is version 4.1.0-1.

I'm unsure what the underlying issue or fix was, but I very much appreciate your efforts in getting this resolved. As far as I'm concerned this bug can be closed.

Kind regards,
Peter Kroon

Hi,

Am 26.01.26 um 10:38 schrieb Kroon PC, Peter:
why would one do that? :)
That version does not exist. Which version do you mean?

Yeah. Count me confused :)

Especially since the original report #1113713 actually *was* against 25.2.3-1 and there were no apparmor changes since then (in contrast to 26.2.x ;) and the mentioned

which might mean the discussion in https://gerrit.libreoffice.org/c/core/+/190686/comments/90fcd4d9_158418fb aka
"#959399: This one's easy: AppArmor has a @{HOMEDIRS} tunable that exists for this very purpose. On Debian-based systems, all you need to do is dpkg-reconfigure apparmor and set it up appropriately."
should now work.

)


Regards,

Rene

Hi,

Outlook doesn't like inline replies unfortunately.
This was my original workaround :)
Sorry, my bad. apt-cache policy says 4:25.2.3-2+deb13u3 is installed.
$ cat /etc/apparmor.d/tunables/homes.d/site.local
...
@{HOMEDIRS}+=/homes/

¯\_(ツ)_/¯

Thanks!
Peter

why would one do that? :)
That version does not exist. Which version do you mean?

Yeah. Count me confused :)

Especially since the original report #1113713 actually *was* against 25.2.3-1 and there were no apparmor changes since then (in contrast to 26.2.x ;) and the mentioned

which might mean the discussion in https://gerrit.libreoffice.org/c/core/+/190686/comments/90fcd4d9_158418fb aka
"#959399: This one's easy: AppArmor has a @{HOMEDIRS} tunable that exists for this very purpose. On Debian-based systems, all you need to do is dpkg-reconfigure apparmor and set it up appropriately."
should now work.

)


Regards,

Rene