It is possible to just not use snap on ubuntu. The few ubuntu servers we have, even the couple with a minimal XFCE interface for some gui pieces, don't have snap installed. I realise local exploits happen all the time, but why add a whole new huge surface area if I don't have to.
I wonder if, and this is just speculating not trying to start an arguement, if this sort of thing could have happened in the simpler pre-snap, pre-systemd systems? More to the point is this a cause of using more complicated software?
Permission and timing gotchas in /tmp predate snap and systemd. It's why things like `mkstemp` exist.
I remember cron jobs that did what systemd-tmpfiles-clean does before it existed. All unix daemons using /tmp run the risk of misusing /tmp. I don't know snap well enough to say anything about it makes it uniquely more susceptible to that.
Rust cannot help you if race condition crosses API boundary. No matter what language you use, you have to think about system as a whole. Failure to do that results in bugs like this
The bigger problem here is it seems like the rust utilities were rushed to be released without extensive testing or security analysis because simply because they are written in rust. And this isn't the first serious flaw because of that.
Doesn't surprise me coming from Canonical though.
At least that's the vibe I'm getting from [1] and definitely [2]
It is possible to just not use snap on ubuntu. The few ubuntu servers we have, even the couple with a minimal XFCE interface for some gui pieces, don't have snap installed. I realise local exploits happen all the time, but why add a whole new huge surface area if I don't have to.
Better to follow the link to the technical details and just read those: https://cdn2.qualys.com/advisory/2026/03/17/snap-confine-sys...
The article linked in the submission is more verbose but less clear and half of it is an advertisement for their product.
Semi-related: does anybody know of a reliable API that announces CVEs as they're published?
Edit: for others who may be curious https://www.cve.org/Downloads
When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.
I wonder if, and this is just speculating not trying to start an arguement, if this sort of thing could have happened in the simpler pre-snap, pre-systemd systems? More to the point is this a cause of using more complicated software?
Permission and timing gotchas in /tmp predate snap and systemd. It's why things like `mkstemp` exist.
I remember cron jobs that did what systemd-tmpfiles-clean does before it existed. All unix daemons using /tmp run the risk of misusing /tmp. I don't know snap well enough to say anything about it makes it uniquely more susceptible to that.
The mistake seems to be using a predictable path (/tmp/.snap) in a publicly-writable directory.
1 reply →
[flagged]
Rewrite tools in new language, get new exciting bugs!
Rust cannot help you if race condition crosses API boundary. No matter what language you use, you have to think about system as a whole. Failure to do that results in bugs like this
The bigger problem here is it seems like the rust utilities were rushed to be released without extensive testing or security analysis because simply because they are written in rust. And this isn't the first serious flaw because of that.
Doesn't surprise me coming from Canonical though.
At least that's the vibe I'm getting from [1] and definitely [2]
[1] https://cdn2.qualys.com/advisory/2026/03/17/snap-confine-sys... [2] https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
1 reply →