Hacker News

I love that cheeky "oh btw, there's also another vulnerability in rust coreutils rewrite, but we aren't talking about that" paragraph

This.

Might be worth updating the link.

Pop!_OS is basically Ubuntu without snap. Debian is fine, but for some reason it is ugly. Like, you can style and configure it with a thousand options, but simply fails to have a nice theme and UI out of the box.

Have you tried Debian with the XCFE desktop? Should be pretty similar to Xubuntu (but without Snap, of course)

Worth looking at Fedora. Been using it for work and play for over a decade and it's never let me down. Absolutely solid.

I love multipass. It is a simple no BS virtualization solution and probably the best thing to come out of Ubuntu after LXD.

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

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

Rewrite tools in new language, get new exciting bugs!

Is a race condition a memory related error?

> (a Rust rewrite of the standard GNU coreutils -- ls, cp, rm, cat, sort, etc), which are installed by default in Ubuntu 25.10.

0 benefits and only risks involved. Users are forced to choose between a worse new version or an older version that will no longer be supported. Like SystemD all over again.

It feels like there is a phenomenon where software devs (especially Open Source) have to keep developing even when just doing nothing would result in a better product. Like there's some monetization incentives to keep touching the thing so that you can get paid.

They publish on GitHub now https://github.com/CVEProject/cvelistV5

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

We have notifications set up at my job for criticals and I quickly have learned how many 10.0 CVE's are related to random IoT devices that I can't even find via google.

Without snap, the front door is wide open: all applications you run are unconfined within your user account and can snoop on all of your files. On a normal single-user desktop system, almost everything valuable is within your user account, not root. If an attacker does want root (such as to install a rootkit that can hide itself or to access other user accounts), they can install an alias to sudo on your account and piggy-back on the next time you use it.

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.

Well yeah, if everything runs unsandboxed as root then there are no privilege escalations!

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.

This isn't really systemd's fault at all. Systemd just happens to be what cleans up /tmp. You would have the same problem with tmpreaper.

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

It absolutely could have happened when the ecosystem norm is `curl https://third.party/installer|sudo sh`. That was the normal method for third parties to ship software before snaps came along.

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.

I think a better question is whether there are simpler approaches to sandboxing applications that avoid this problem by design.

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.

> Linux does have something similar with $XDG_RUNTIME_DIR (generally /run/user/$UID/), but it's stored in memory only

On a lot (at this point I assume most) of systems /tmp is also just a tmpfs, so it also is just in memory. /var/tmp usually is storage backed though.

> I wish there was a common convention for user-specific temp directories on Linux

There kind of is. /run/user/$userId is part of a tmpfs and is owned by the user. But it isn't always used when it should be.

Systemd also has a mechanism to create private /tmp directories for services.

>which requires a reboot every 4 years

We have a monitoring check and once a system reaches 200 days of uptime we start scheduling a reboot. Because you KNOW there are kernel and library updates that are probably hanging around on disc but not in memory. I used to be an uptime snob, but I've decided it does more harm than good.

Slightly related: A coworker was doing a RAM upgrade on a Sun box. I suggested that before they cracked the hardware open, they first shut it down, and then power it back on, just to make sure it would. So they wouldn't go chasing down a RAM upgrade issue when it was the system itself. I want to say that this system had years of uptime since it was last rebooted, let alone powered off. He was very glad I suggested that, because it indeed did not come back up after the power cycle.

If you care about slow tmp leaks, you could also just use a 1-line, decade+ old solution; no additional software required, since your machine already has cron, find and xargs on it:

https://askubuntu.com/questions/431058/using-a-cronjob-to-cl...

If you miss that "will this eat my system?" adrenaline rush you get from systemd-tmpfiles, you could just use cron + find, but replace xargs with the -delete option.

>Ubuntu is even on the radar anymore

The biggest thing that has prevented me from switching prod systems to Debian is that the window for updates is fairly small, at around a year. 13 came out Aug 9, 2025, and 12 goes EOL June 10, 2026. Compared to Ubuntu 24.04 coming out in April 2024, and 22.04 goes EOL in May 2027 (a year after 24.04). So Ubuntu covers 2 releases plus a year.

I know a lot of people feel like this isn't a big deal, but even with Ansible it can be hard to get our fleet of a few hundred machines all upgraded in a year window, being already busy. Some of them are easy, of course, but there are some that take significant time and also involve developer work, etc...

Don't get me wrong, I think Debian is great. But in the data center, there's definitely a case for a longer support window, and I like that about Ubuntu. RHEL is even better for that, but it is very nice that Ubuntu free and Ubuntu commercial are the same, but with RHEL there is that split to CentOS being the free one (haven't used RHELs in quite a while, obviously).

Debian is almost as broken as Ubuntu.

However, I've been extremely happy with Devuan. It is Debian minus some bad decisions the Ubuntu voting block forced upstream (for instance, there's no systemd).

It can be done, but it is quite irritating with the way that canonical have made snap a dependency in the minimal meta package. (And minimal on Ubuntu is really really super minimal, doesn't even have ping. Well apart from snap anyway).

They really went out of their way to make it awkward and annoying to take snap out.

But why bother running Ubuntu at all just to jump through hoops to avoid snaps? Snaps are obviously Ubuntus the thing, so feels counterproductive to run Ubuntu and fight against it.

use debootstrap to install instead, chroot is your friend. It comes with nothing and I mean that literally while still having the superior ubuntu kernel.

Snap supports programs running as real root. Would those work with user namespaces?

There are several reasons but at some point we can use user namespaces to remove them. I'm not particularly a HN person so I won't go into details but it's possible to drop the setuid bits sooner rather than later.

[dead]

Probably never for package based distros. I could see it happening for image based distros, where systemd is slowly but surely providing all the building blocks for. It has had the option for `NoNewPrivileges=` in the `system.conf` since v239, so it isn't exactly difficult to disable for the entire system.

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.

Around 20 years after suid is deprecated.

> 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 <string.h>
  #include <stdlib.h>
  #include <stdio.h>
  #include <unistd.h>
  
  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;
  }

Why are you stuck on Ubuntu, what is holding you back?

[dead]