Default to switches::kNoSandbox when confined inside a snap
Bug #1651166 reported by
Olivier Tilloy
This bug affects 2 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Oxide |
Won't Fix
|
Medium
|
Unassigned | ||
Bug Description
Because of bug #1599234, the oxide sandbox doesn’t work inside snaps. Until a better long-term solution emerges (userns sandbox), it would be useful if oxide defaulted to disabling the sandbox when it detects it’s running confined inside a snap, so as to avoid the situation described in https:/
| Changed in oxide: | |
| assignee: | nobody → Olivier Tilloy (osomon) |
| milestone: | none → branch-1.21 |
| status: | New → In Progress |
| importance: | Undecided → Medium |
Revision history for this message
| Chris Coulson (chrisccoulson) wrote | #1 |
Revision history for this message
| Olivier Tilloy (osomon) wrote | #2 |
| Changed in oxide: | |
| status: | In Progress → Won't Fix |
| milestone: | branch-1.21 → none |
| assignee: | Olivier Tilloy (osomon) → nobody |
To post a comment you must log in.
I'm strongly opposed to any sandbox disable in Oxide that isn't absolutely explicit. A dedicated environment variable to disable the sandbox, which we already have, is fine. But I'd rather not be adding conditions that implicitly disable the sandbox. I'd prefer Oxide to maintain the Chromium behaviour where a lack of sandbox is fatal unless explicitly requested.