Public bug reported:
1) Ubuntu release
$ lsb_release -rd
Description: Ubuntu 26.04 LTS
Release: 26.04
2) Package version
$ apt-cache policy apparmor
apparmor:
Installed: 5.0.2-0ubuntu1~26.04.1
Candidate: 5.0.2-0ubuntu1~26.04.1
(also: fuse3 3.18.2-1, flatpak 1.16.6-1, xdg-desktop-portal
1.21.1+ds-1ubuntu3,
kernel 7.0.0-30-generic)
3) What I expected to happen
xdg-document-portal mounts its FUSE filesystem at /run/user/<uid>/doc when
the
session starts, so bwrap can bind the per-app document directory and Flatpak
applications launch.
4) What happened instead
The setuid fusermount3 helper spawned by the portal hangs and never completes
the mount. The systemd unit still reports "active (running)" while
/run/user/1000/doc stays empty, and from then on EVERY Flatpak app fails to
launch with:
bwrap: Can't find source path /run/user/1000/doc/by-app/<app-id>:
No such file or directory
Recovering needs "systemctl --user restart xdg-document-portal.service".
Root cause is four missing permissions in the fusermount3 AppArmor profile;
details, kernel-log evidence and a verified fix below.
## Summary
On Ubuntu 26.04 the shipped `/etc/apparmor.d/fusermount3` profile denies four
things the setuid `fusermount3` helper needs when `xdg-document-portal` mounts
its FUSE filesystem. Intermittently the helper then *hangs* rather than failing,
so `/run/user/<uid>/doc` is never mounted while the systemd unit still reports
`active (running)`. Once that happens, **every** Flatpak app fails to launch:
bwrap: Can't find source path /run/user/1000/doc/by-app/<app-id>: No
such file or directory
This is a launch-path failure, distinct from the install-path failures in
LP #2122161 and LP #2130388.
## Why this matters for the decision taken in LP #2122161
LP #2122161 comment #11 asked whether `CAP_DAC_OVERRIDE`/`CAP_SETUID` were
actually needed; comment #12 tested and reported flatpak working with only the
`utab.lock` rule, and the capabilities were deliberately left out with the note
now carried in the profile:
# Flatpak seems to work fine without these capabilities, so don't grant
# them unless actual functionality breakage is caused elsewhere
That testing covered `flatpak install` only. The document-portal path invokes
fusermount3 differently — a long-lived session mount instead of a one-shot
unmount of the download cache — and there the denial is not harmless.
Direct evidence: the helper that hung at session start, pid 8673, logged
**only**
the two capability denials and never reached the mount step at all, whereas
helpers that went on to mount successfully also logged mount denials:
audit: apparmor="DENIED" operation="capable" class="cap"
profile="fusermount3" \
pid=8673 comm="fusermount3" capability=1 capname="dac_override"
audit: apparmor="DENIED" operation="capable" class="cap"
profile="fusermount3" \
pid=8673 comm="fusermount3" capability=7 capname="setuid"
State of the wedged helper (sleeping indefinitely, parent is the
portal):
$ ps -ef | grep fusermount
root 8673 8625 fusermount3 -o
rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/1000/doc
$ grep -c fuse.portal /proc/mounts # -> 0, mount never established
$ systemctl --user is-active xdg-document-portal.service
active # unit lies about the mount
Note that LP #2122161 comment #14 (Christian Boltz, AppArmor upstream) already
suggested `capability setuid,` may legitimately be needed so fusermount3 can
drop
to a less-privileged user.
## The full denial chain
The four missing permissions only surface one at a time — granting each lets the
helper advance to the next denial. In order:
1. capabilities, as quoted above:
capname="dac_override" / capname="setuid"
2. libfuse >= 3.17 makes its mount namespace private before mounting:
operation="mount" class="mount" info="failed mntpnt match" error=-13 \
profile="fusermount3" name="/" flags="rw, rprivate"
3. it then rbinds the user runtime dir inside that namespace:
operation="mount" class="mount" info="failed flags match" error=-13 \
profile="fusermount3" name="/" srcname="/run/user/1000/" flags="rw,
rbind"
4. and it opens the mountpoint directory, which the profile permits mounting on
but not reading:
operation="open" class="file" profile="fusermount3" \
name="/run/user/1000/doc/" requested_mask="r" denied_mask="r" \
fsuid=1000 ouid=1000
## Reproduction
Not reliably reproducible on demand — it is a race, hit twice on this machine
(2026-07-15 and 2026-08-25), each time at session start. Detection is reliable:
grep fuse.portal /proc/mounts # empty => wedged
ls /run/user/$UID/doc/ # empty
flatpak run <any-app> # bwrap: Can't find source path
.../doc/by-app/...
Recovery without root: `systemctl --user restart xdg-document-
portal.service`.
## What fixes it
`/etc/apparmor.d/local/fusermount3`:
capability dac_override,
capability setuid,
mount options=(rw, rprivate) -> /,
mount options=(rw, rbind) @{run}/user/@{uid}/ -> /,
@{run}/user/@{uid}/**/ r,
then `apparmor_parser -r -T -W /etc/apparmor.d/fusermount3`.
Verified afterwards: 9 consecutive portal restarts all established the mount,
four Flatpak apps launch, and **zero** AppArmor denials of any profile are
logged.
Survives `systemctl reload apparmor.service`; `apparmor_parser -Q --debug` shows
`Capabilities: dac_override dac_read_search net_bind_service setuid sys_admin`.
Rules 2-4 look like they belong in the shipped profile regardless of the
capability question, since they track libfuse 3.17+ behaviour that the profile
was never updated for.
## Environment
Ubuntu 26.04 LTS, kernel 7.0.0-30-generic (x86_64)
apparmor 5.0.2-0ubuntu1~26.04.1
fuse3 / libfuse3-4 3.18.2-1
flatpak 1.16.6-1
xdg-desktop-portal 1.21.1+ds-1ubuntu3
Desktop: GNOME/Wayland. Local uid 1000, no authd, sssd installed but
inactive.
## Related
* LP #2122161 - Fix Released. Install path. Source of the decision not to
grant
the capabilities; this report is the "actual functionality breakage ...
elsewhere" that its profile comment anticipated.
* LP #2129704 - In Progress. Also "document portal broken due to apparmor
blocking fusermount3", but the authd/NSS variant ("could not determine
username", connect denied to /run/authd.sock). apparmor!1895 shipped
abstractions/authd in 5.0.2, so that variant is already fixed here and is
not
this bug - no authd on this machine.
* LP #2130388 - Confirmed. Install path via Bazaar; different denials
(fuse fd over unix socket).
** Affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Tags: apparmor flatpak fusermount3 portal
** Tags added: flatpak fusermount3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2165030
Title:
fusermount3 profile wedges xdg-document-portal: no FUSE mount, all
Flatpak apps fail to launch
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2165030/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
