In Jammy, we still have an old-school init script that's invoked to set up the crash handler at the kernel level. As part of the script, there an unconditional `chmod 1777 /var/run`. However, surprisingly, `chmod 1777` on a 3777 file will result in a 3777 file (that's actually documented in the man page). To confirm, I straced the chmod execution, and the syscall is fed 3777, so we can't even blame this on the kernel ;).
In the Lunar cycle we moved away from the init file to use a proper service file instead (see https://github.com/canonical/apport/pull/38 ). As part of this move, the `chmod(1)` call was translated into a Python `os.chmod` call, which will do a straight syscall without the fancy logic of chmod(1), with the end result of whoopsie being unable to read Python crash files.
I've finally tracked down the permission issue:
In Jammy, we still have an old-school init script that's invoked to set up the crash handler at the kernel level. As part of the script, there an unconditional `chmod 1777 /var/run`. However, surprisingly, `chmod 1777` on a 3777 file will result in a 3777 file (that's actually documented in the man page). To confirm, I straced the chmod execution, and the syscall is fed 3777, so we can't even blame this on the kernel ;).
In the Lunar cycle we moved away from the init file to use a proper service file instead (see https:/ /github. com/canonical/ apport/ pull/38 ). As part of this move, the `chmod(1)` call was translated into a Python `os.chmod` call, which will do a straight syscall without the fancy logic of chmod(1), with the end result of whoopsie being unable to read Python crash files.