snap-confine misbehaves if /run/snapd/ns is a shared mount point

Bug #1803542 reported by Zygmunt Krynicki
6
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.

Zygmunt Krynicki (zyga)
Changed in snapd:
status: Confirmed → In Progress
Revision history for this message
Zygmunt Krynicki (zyga) wrote :

This is fixed with the following PR: https://github.com/snapcore/snapd/pull/6159

Zygmunt Krynicki (zyga)
Changed in snapd:
milestone: none → 2.37
status: In Progress → Fix Committed
Zygmunt Krynicki (zyga)
Changed in snapd:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.