© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
There 3 profiles involved here (probably should be 4), with a call dependency chain of
flatpak -> bwrap -> bwrap_unpriv
the flatpak profile does not show up in the logs but does end up launching bwrap. The comm is being set by flatpak, and can not be considered reliable for which executable is running for a given entry. The bwrap profile will be recorded for while bwrap code is running, and bwrap_unpriv AND bwrap stacked for the actual keepassxc application.
There are 2 distinct class of failures here
1. Deleted files being re-validated. These have the info="Failed name lookup - deleted dentry". Basically fd delegation is not allowed to by-pass mediation. The files are no longer part of the namespace, and were never validated for access under the current confinement.
2. files that are in the namespace that the application doesn't have permissions to access.
breaking this down by profiles
bwrap:
l /home/*
l /home/*
unpriv_bwrap:
l /home/*
l /home/*
that bwrap and bwrap_unpriv are attempting to do the same thing, and each once with a deleted file then again with one that exists is extremely interesting. I need to dig into this a little more, to figure out exactly what is going on.
The 2nd entry at first pass should be allowed by the profile, unless it is related to the same syscall that is causing the deleted entry denial, and is do to stacking denying the deleted dentry. If that is the case the question becomes how does the dentry stop being deleted during the single syscall. Like I said further investigation is needed.