As I mentioned previously the problem is evident right there:
> % getcap /usr/lib/snapd/snap-confine
>
> /usr/lib/snapd/snap-confine
> cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_sys_chroot,cap_sys_ptrace,cap_sys_admin=p
lists cap_fowner
> 2025/10/16 18:41:44.731926 logger.go:289: DEBUG: -- snap startup
> {"stage":"snap to snap-confine", "time":"1760632904.731923"}
> DEBUG: -- snap startup {"stage":"snap-confine enter",
> "time":"1760632904.734016"}
> DEBUG: caps at startup:
> cap_chown,cap_dac_override,cap_dac_read_search,cap_sys_chroot,cap_sys_ptrace,cap_sys_admin=p
cap_fowner is gone, but how?
I'm trying to investigate this from AppArmor angle now. I am only able
to reproduce the problem iff I deliberately comment our or remove
`capability fowner,` from snap-confine AppArmor profile. Then the
capability is gone at runtime, the output looks like reported here, yet
no denials or other messages indicating that the capability was stripped
are logged in dmesg.
A question to anyone reporting this problem. Do you happen to use LXD
and have a container which uses security.privileged=true,
security.nesting=true and sets lxc apparmor profile to unconfined? As
this could lead to a situation in which the container could actually be
setting up an older profile but affecting the host's kernel.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2127224
Title:
all snaps fail to run
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2127224/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
