snap-confine misbehaves if /run/snapd/ns is a shared mount point
Bug #1803542 reported by
Zygmunt Krynicki
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| snapd |
Fix Released
|
Medium
|
Zygmunt Krynicki | ||
Bug Description
The logic inside snap-confine attempts to ensure that /run/snapd/ns is a private mount point. That is, that it has private sharing so that mount events don't propagate anywhere. The check there is simplistic, looking for private mount point or for lack of thereof.
If /run/snapd/ns is a mount point but it is not privately shared then the logic misbehaves, putting a non-recursive bind mount from /run/snapd/ns over itself.
This was found in exploratory testing and debugging session.
| Changed in snapd: | |
| status: | Confirmed → In Progress |
Revision history for this message
| Zygmunt Krynicki (zyga) wrote | #1 |
| Changed in snapd: | |
| milestone: | none → 2.37 |
| status: | In Progress → Fix Committed |
| Changed in snapd: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
This is fixed with the following PR: https:/