Package: libreoffice-common
Version: 4:24.2.7-0ubuntu0.24.04.6
Title: AppArmor lu*.tmp rule still denies saving at the UPPER bound: 7-digit
PIDs produce 13-char names (variant of Debian #1090814)
This is the same family of bug as Debian #905442, #1004038 and #1090814, but at
the opposite end of the range, and the fix for #1090814 does not address it.
All saving fails in every LibreOffice application with "the file could not be
written", for every format and every location under $HOME, /mnt and /media,
including a brand-new empty document. AppArmor denies creation of the temporary
file that LibreOffice writes before renaming it onto the target:
apparmor="DENIED" operation="mknod" class="file" profile="libreoffice-soffice"
name="/home/username/Desktop/lu19707331lthx2.tmp" requested_mask="c"
denied_mask="c" comm="soffice.bin"
THE TEMPORARY NAME LENGTH TRACKS THE PID
The name is the PID, then one digit, then five characters:
lu19707331lthx2.tmp <- pid 1970733 + "1" + "lthx2" = 13 chars after "lu"
lu19724381lvd02.tmp <- pid 1972438 + "1" + "lvd02" = 13 chars after "lu"
All 21 distinct denied names captured over six hours were exactly 13 characters.
So the length is a function of how many digits the PID has:
5-digit PID -> 11 chars
6-digit PID -> 12 chars
7-digit PID -> 13 chars
WHY THE EXISTING FIX DOES NOT COVER THIS
Ubuntu 24.04, libreoffice-common 4:24.2.7-0ubuntu0.24.04.6, line 111:
owner @{libo_user_dirs}/{,**/}lu????????{,?,??,???,????}.tmp rwk,
-> permits 8 to 12 characters
Fix for #1090814, in libreoffice 4:25.2.3~rc1-1:
owner @{libo_user_dirs}/{,**/}lu???????{,?,??,???,????,?????}.tmp rwk,
-> permits 7 to 12 characters
That fix lowered the floor from 8 to 7, which addresses the short-name reports.
The ceiling is unchanged at 12, so a 7-digit PID still yields 13 characters and
is still denied. Both the shipped Ubuntu profile and the fixed Debian profile
fail this case.
WHY THIS IS NOT RARE, AND WHY IT LOOKS INTERMITTENT
kernel.pid_max is 4194304 by default on Ubuntu 24.04, set in
/usr/lib/sysctl.d/50-pid-max.conf, so 7-digit PIDs are reachable on any stock
install. Whether a machine gets there depends only on how fast it consumes PIDs.
On the reporting machine, a normally-loaded desktop (browsers, containers, a
database, several terminals) sustains about 14 new PIDs per second, roughly 1.2
million per day. It crosses PID 1,000,000 about 19 hours after each boot, and
from that moment LibreOffice cannot save anything until the next reboot.
That behaviour explains why this is easy to misdiagnose:
- it does not reproduce on a freshly booted test machine;
- rebooting appears to "fix" it, so users reboot and never report it;
- it is total when it happens, not intermittent, but only after a threshold;
- suspend/resume does not reset PIDs, so a laptop that is suspended rather
than shut down accumulates across days.
Any long-running host that drives LibreOffice headlessly for document conversion
will hit this much sooner, and will stay broken.
SUGGESTED FIX
Make the rule independent of the PID's length, since any fixed-length glob has
now failed at both ends and will need revisiting again as pid_max rises:
owner @{libo_user_dirs}/{,**/}lu*.tmp rwk,
Verified on the reporting machine: applying that and reloading with
apparmor_parser -r took mknod denials from 21 to 0, with the profile still in
enforce mode.
VERSIONS
libreoffice-common 4:24.2.7-0ubuntu0.24.04.6
libreoffice-calc 4:24.2.7-0ubuntu0.24.04.6
apparmor 4.0.1really4.0.1-0ubuntu0.24.04.7
Ubuntu 24.04, x86_64, kernel 7.0.0-28-generic
TO REPRODUCE
On a system whose current PIDs have 7 digits (check with:
cat /proc/sys/kernel/ns_last_pid
), open any LibreOffice application, create a new empty document and save it
anywhere under $HOME. The save fails, and a matching operation="mknod" denial
appears in the kernel log. To reach that state quickly on a test machine, raise
the PID counter directly:
echo 1000000 | sudo tee /proc/sys/kernel/ns_last_pid
