CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root (blog.qualys.com)

Might be worth updating the link.

But I can't use it. You know why? Because despite being open source Canonical wont tell you how to compile it and install it as a standalone program. Instead all their documentation says "install via snap"... even if your are on fedora or debian or arch:

https://github.com/canonical/multipass

Snap needs to die, it is hurting everybody including canonical

If you need metadata added by NVD, NVD website documents their API.

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.

Less pithy, i seem to recall many issue with programs that relied on suid and permission dropping, which would be the 'oldschool' way of firming up the above.

You're not wrong that complexity has been introduced, and I'm not a a fan of snap either, but ultimately sandboxes (esp backwards compatible ones that don't need source level modifications) are complex.

If you want simple and secure, you're probably looking at OpenBSD and pledge.

The problem is snapd not protecting against something else writing to /tmp.

We have Flatpaks to solve this problem too now, but AFAICT while Flatpaks do support sandboxing the UX for that is such that most Flatpak non-power-users aren't enforcing sandboxing on Flatpaks they install, so in practice the feature isn't present where it's most needed.

The answer is definitely "yes". Many articles and books have been written about UNIX administration, and separating accounts, even without jails.

With jails, you could do even better.

Though you'd be surprised how many binaries are suid binaries while they probably shouldn't be (passwd, mount, groupmems, ...), though alot can also work without being suid just more resticted in what they can do.

> When will these distros accept suid was a mistake and disable it.

I have the following C program that I use as an unprivileged user to put my system into and out of Game Mode.

1) Do you believe that this program is unsafe when compiled and set suid root?

2) How do you propose that I replace it with something that isn't suid root?

  #include 
  #include 
  #include 
  #include 
  
  void maybe_do(const char * cmd) {
    if(system(cmd)) {
      perror(cmd);
      exit(2);
    }
  }
  
  int main(int argc, char** argv) {
    if(argc != 2) {
      return 1;
    }
    int turnOff = strncmp("on", argv[1], 2);
  
    if(setuid(0)) {
      perror("uid");
      return 2;
    }
    if(turnOff) {
      maybe_do("/usr/bin/cpupower frequency-set --governor schedutil > /dev/null");
      maybe_do("/bin/echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level");
    } else {
      maybe_do("/usr/bin/cpupower frequency-set --governor performance > /dev/null");
      maybe_do("/bin/echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level");
    }
    return 0;
  }