It's a race condition that can be used as a primitive to achieve privilege escalation which makes it legitimate but even if it you couldn't use it for anything else but to trick the system into acting on a directory it didn't meant to it would still be a valid vulnerability (regardless of the application).
Claiming it's not a valid bug would be similar to claiming an infoleak isn't as well when it's one of the building blocks of modern exploitation.
I'm not trying to be an ass, I'm just trying to add a bit of context to ensure that the implication is well understood.
But this vulnerability is enabled by a very creative exploitation of the complicated bind mounting scheme used by snap-confine. Just reading about these mounts between /usr/lib to /tmp and back triggered my sense of a potential security vulnerability.
Slightly tangential but I never ended up switching to nix (or guix) precisely because I don't fully understand the theory behind why things were done the way they were done and where the security boundaries are supposed to lie relative to a "regular" distro. I found plenty of prescriptive documentation giving me recipes to do anything I might be interested in doing but not much in the way of design documents explaining the system itself.
I never asked around so maybe that's on me. Debian works just fine though and containers are (usually) simple enough for me to wrap my head around.
I didn't end up using Flatpak for the same reason.
NixOS is incredibly complicated at build time, but the filesystem & runtime state is pretty simple. Run it in a VM and look around, there's very little magic at runtime; the trickery is mostly in the build time rpath hack to load shared libs from the specific /nix/store paths, and a lot of configuring software to read files from specific /nix/store paths.
When you sandbox your apps on debian already, there should be no security difference doing so on nixos, no?
The globally accessible /nix/store is frigthening, but read-only. Same applies to the nixos symlinks pointing there. This vulnerability was enabled by a writable /tmp and a root process reaching into it. This would be bad on debian and nixos.
I'm not suggesting the presence of a vulnerability just that I'm not comfortable switching to a complex system where I have little to no understanding of the logic behind the design. My remarks were nothing more than a tangential gripe.
I don't like snap and have always uninstalled it in the past. However, that gets more difficult in newer releases, so probably not a sustainable path. Still searching for the distro I could install instead of Xubuntu for friends and family who don't want or need the latest and greatest.
The main reason for my dislike is the closed source nature of snap distribution.
App isolation is important and not easy. That bugs will happen and be fixed there is natural. Happens with every other system that was supposed to increase security, too.
Me too. Switching my home system from Ubuntu back to Debian was influenced a lot by snap. I don't get how they could fumble that one so hard. It goes against everything they used to stand for. If I want a bloated, slow, closed-source, proprietary app store with unclear security ramifications, I'll install MacOS or Windows. It also feels like app developers at least care a little bit about those stores. Mozilla for example still officially recommends installing their Debian package rather than through snap on Linux, despite shipping via snap by default on Ubuntu now.
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.
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:
I think pointing end users to use the end user packaged app is fine, as is to trust people who are comfortable with building from source to find the build docs from the repo.
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.
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?
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.
The exploit doesn't rely on the path being predictable though.
As I read it the .snap is expired and pruned, then the exploiter makes their own .snap in /tmp, then snap-confine assumes that the new .snap is the old one and executes with elevated privileges.
So, the path can be from mkstemp, or a sha-256 of your significant others fingerprint, it doesn't matter; until it expires it's plaintext in the /tmp listing.
{Wild, ignorant speculation follows ... hashing the inode and putting a signed file in the folder bearing that hash, then checking for that ... something that works but along those lines might be appropriate. (We know the inode for the 10 days we're waiting for /tmp/.snap to get pruned; time that might be used to generate a hash collision, so my off-the-cuff suggestion is definitely no good. It feels like there's a simple solution but everything I can think of fails to KPA, I think -- perhaps just use dm-crypt for the /tmp/.snap folder?}
Or just assert the UID and GID of /tmp/.snap before using. Of course, you'd want to open(2) /tmp/.snap and use fstat(2) on a descriptor (not just pass the path, /tmp/.snap, to stat(2)), then use mkdirat, openat & friends consistently.
Yes, it does. The attacker knows that snap is going to look in /tmp/.snap/, instead of e.g. /tmp/.snap.FjBz8oEWaU/ (which isn't guessable in advance) so when /tmp is flushed, he just has to recreate /tmp/.snap/ before snap-confine does, and drop his payload there.
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.
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.
The frustrating part is that Snap's confinement story was supposed to be a selling point. Here we are with a priv-esc in the daemon itself. At this point I've just disabled snapd on all our Ubuntu boxes and moved to flatpak or building from source. The attack surface of a privileged install daemon that parses arbitrary package manifests is just too broad.
The shared /tmp/ directory that can be used by processes of multiple users seems extremely prone to causing this type of issue. I wish there was a common convention for user-specific temp directories on Linux, because a whole class of vulnerabilities could go away.
MacOS handles this great by setting $TMPDIR to some /var/folders/.../ directory that's specific to the current user. Linux does have something similar with $XDG_RUNTIME_DIR (generally /run/user/$UID/), though it's stored in memory only which is a little different from usual for /tmp/, seemingly mainly intended for small stuff like unix sockets.
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.
With https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.
Isn't the issue in this case caused not by suid, but by a daemon running as root reading files from a tmp dir? Seems like a socket-activated daemon wouldn't solve this specific case.
systemd-homed stores most of the user specific information in the home directory `~/.identity`, but since the file contents have to be signed the changes need to be done though a daemon, which is talked to via IPC (homectl does the talking to systemd-homed).
First off, thanks very much for giving me exactly what I asked for.
You propose that instead of sometimes running ~five lines of C as root, I do one of the following:
1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in.
2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs.
3) Use a package that has several-thousand lines of C (and who knows how many lines of Python) running as root and does way more than I need.
All of these alternatives tell a story:
The alternative to running ~five lines of C as root is to run *many* more lines as root.
This is kinda my point. Some people rave about setuid programs and assert that they should not exist, but when you absolutely need to let an unprivileged user do things that only root is ordinarily permitted to do you're going to have to have code running as root. And when you have code running as root, you have to be careful to get it right. Whether it's running from a setuid root-owned executable, a persistent daemon running as root, or a regular program that sudo [1] has executed as root is irrelevant: it's all code running as root!
[0] People shit on sudo for both being setuid root and for being "too complicated". I love the hell out of the program; it's an essential part of how I get shit done on my PC. sudo is -very seriously- a great tool.
Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).
The systemd service executable is just your simple C program as-is.
Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.
I think the only thing that I find kinda strange about setuid/setgid is the fact that it is tied to an executable rather than as part of the executing principal.
As an example of an OS that doesn't use a concept, Windows only recently got Unix domain sockets (which is kinda the standard for IPC in *nix land) and generally used named pipes, mailslots, etc for IPC, which can be ACLed. Communication with services and elevation after Windows XP[1] was based on the the user's privileges and not "uid == 0" or "bit set on a file"
[1]: Before Vista, a lot of services actually straight up did show UIs on the desktop or whatnot. It was found though that doing this was pretty bad as you could use automation tools to drive the UI and it could lead to some pretty nasty local privilege escalations.
Yup! There's no way around that if in the end you need elevated privileges somewhere.
What the other options allow is to contain the blast radius. With the daemon you can control access via groups on the socket, and with sudo you can control access via sudoers.d
...huh. There isn't. I checked out the git repo, and read the contents of the daemon directory. I guess I looked at the meson stuff at top level and thought to myself "Meson? Isn't that one of the half-billion Python build systems?" [0] and -from that thought- assumed that there was some Python in the directories I didn't examine. (It turns out that there is not. It's all C and configuration.)
> What the other options allow is to contain the blast radius.
I can do that by removing the "other" executable bit, adding the group executable bit, and setting the file's group appropriately to control access. You are limited to a single group, but it's not like you're unable to "contain the blast radius".
> With the daemon you can control access via groups on the socket...
As long as it's a UNIX socket, yes. (Getting guaranteed information about the identity of the process on the other side of such a socket is one of my favorite things about them.)
> Yup! There's no way around that if in the end you need elevated privileges somewhere.
Exactly. I hope the "setuid is evil and shouldn't exist" people who are complaining in good faith are capable of both realizing this and also recognizing that "just daemonize it" and "just run it with sudo" are -at times- not obviously the right thing to do.
Building services should be easy. The fact that Linux does not have an easy to use IPC mechanism is the fault of Linux. Yes, systemd can make it so services don't have to run until they are connected, and yes dbus exists, but it's overcomplicated for something which should be easy to make. This is a Linux devex failure.
>2)
I agree this is going in the wrong direction. Full sudo is also even more in the wrong direction away from only giving the minimal amount of privileges to the code that needs it.
>3)
See my response to 1). Making programs with different capabilities able to talk to each other should be made dead easy to do.
> The fact that Linux does not have an easy to use IPC mechanism...
What? Send bytes down a UNIX socket. There's nothing easier, really. It's so simple, it's what systemd uses to have monitored daemons indicate that they're now actually running.
The rest of your commentary has nothing to do with my commentary about unprivved users running code as root. Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
It really isn't. You have to a whole protocol on top of it if you want to use it and then build out the daemon logic yourself. If it was so easy why didn't you write it instead of making a suid binary. The complexity is not sufficiently abstracted away.
>Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
My whole response was addressing the core of your argument in your post "The alternative to running ~five lines of C as root is to run many more lines as root." The reason it's many more lines is because the Linux developers did not write abstractions to make it simple to do. If you read my original post in this comment chain you will see that I do have problems with setuid executables and want distros to disable them.
> 1) Run a persistent whole-ass daemon using something for IPC
This is the recommended way on Windows as well. Have the (privileged) installer install a privileged service, and have the non-privileged user program communicate with it.
Quite possibly because there are something like two people on earth who understand the Impersonation machinery [0] and one of the two is likely to cause an HN Black Banner Event any day now... so there's no real 'sudo' or 'setuid' equivalent on NT. ;)
[0] Seriously, it's fucking complicated. Decades ago, I wanted to write a sudo for the then-$DAYJOB. I gave up after a week when I couldn't even get the Impersonation equivalent of "Hello world" to work.
In general, I think it's because it tends to be an XY problem. If you're on a service account or something, you generally have SeBackupPrivilege (override read ACLs) and SeRestorePrivilege (override write ACLs) and other relevant privileges so like if you're changing files that's less needed since you can overwrite the ACLs to the necessary files as needed
systemd-tmpfiles bugs the heck out of me. It breaks so many applications for absolutely no good reason. A typical system of mine not running it gathers less than 1GiB per year of uptime in /tmp with disk sizes measured in TB. Even if you are /tmp on a 256GB NVME, that's less than 1% of your total disk per year of uptime. If you upgrade to alternating Ubuntu LTS editions (which requires a reboot every 4 years) systemd-tmpfiles will save you a maximum of 4GB of disk space.
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:
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.
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.
I always wonder why Ubuntu is even on the radar anymore. It is a pile of questionable decisions with a billionaire ego bus factor. If you like apt, just use Debian. sid is fine for desktops if you are moderately technical.
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).
Except their LTS is a lie or maybe plausible deniability for businesses that DGAF. They have no idea what they are doing with backports and lack thereof. And if you aren't paying you aren't even receiving many of the updates.
> And if you aren't paying you aren't even receiving many of the updates.
Are you sure you didn't mean RedHat? Last I checked there's no requirement to pay anything in order to use an LTS release of Ubuntu. Even if you go with Pro to get those extra years of Extended Support (to make it ~12 years?) you still get up to 5 licenses for personal use. No money asked, no *BS* subscription model. Isn't that more than enough any non-commercial user?
Read https://ubuntu.com/security/esm carefully. The chance of running everything out of 'main' is close to zero. I am shocked by how little people understand this.
Main is all you need to set up a working system and deploy services. Much like BaseOS in RHEL you get full support for those packages for 5+5 years. With snaps you effectively get rolling releases of LXD, microk8s, openstack, docker and other relevant things. What else do you need? Seriously, how come this isn't enough for a non commercial user?
Because this is Stockholm syndrome, better community options prevail, main is not all people deploy and is not the only repo default enabled. openstack, docker are legacy tech, never encountered anyone using LXD or microk8s thankfully I'll steer clear of that snap garbage barge.
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 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.
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.
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.
Eh. Definitely not great but until they make it so you can't trivially MitM sudo, I don't think any local privilege execution bugs on Linux are especially notable, at least for most desktop users. Also there's the whole xkcd "at least they can't install drivers" thing.
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]
> Performance is a frequently cited rationale for “Rewrite it in Rust” projects. While performance is high on my list of priorities, it’s not the primary driver behind this change. These utilities are at the heart of the distribution - and it’s the enhanced resilience and safety that is more easily achieved with Rust ports that are most attractive to me.
> The Rust language, its type system and its borrow checker (and its community!) work together to encourage developers to write safe, sound, resilient software. With added safety comes an increase in security guarantees, and with an increase in security comes an increase in overall resilience of the system - and where better to start than with the foundational tools that build the distribution?
So yes, it sounds like the primary official reason is "enhanced resilience and safety". Given that, I would be interested in seeing the number of security problems in each implementation over time. GNU coreutils does have problems from time to time, but... https://app.opencve.io/cve/?product=coreutils&vendor=gnu only seems to list 10 CVEs since 2005. Unfortunately I can't find an equivalent for uutils, but just from news coverage I'm pretty sure they have a worse track record thus far.
> Performance is a frequently cited rationale for “Rewrite it in Rust” projects.
Rewrite from what? Python/Perl? If the original code is in C there _might_ be a performance gain (particularly if it was poorly written to begin with), but I wouldn't expect wonders.
Could be. The thing is, it kinda doesn't matter; what matters is, what will result in the least bugs/vulnerabilities now? To which I argue the answer is, keeping GNU coreutils. I don't care that they have a head start, I care that they're ahead.
That's short sighted. The least number of bugs now isn't the only thing that matters. What about in 5 years from now? 10 years? That matters too.
To me it seems inarguable that eventually uutils will have fewer bugs than coreutils, and also making uutils the default will clearly accelerate that. So I don't think it's so easy to dismiss.
I think they were probably still a little premature, but not by much. I'd probably have waited one more release.
It's extremely early to say if things are rushed or not. It's unsurprising that newer software has an influx of vulnerabilities initially, it'll be a matter of retrospectively evaluating this after that time period has passed.
It's a little different with software since you don't usually have the code or silicon wearing out, but aging software does start to have a mismatch with the way people are trying to use it and the things it has to interact with, which leads to a similar rise of "failure" in the end.
It's not even about API boundaries, it's about logic and the language isn't really responsible for that.
Expecting it to prevent it would be as gullible as expecting it to prevent a toctou or any other type of non trivial vulnerability.
That's why even though I appreciate the role of these slightly safer languages I still have a bit of a knee-jerk reaction to the exagerated claims of their benefits and how much of a piece of crap C is.
Spoiler, crappy programmers write crappy code regardless of the language so maybe we should focus on teaching students to think of the code they're writing from a different perspective and focus safety and maintainability rather than "flashiness"
So I was saying that rust monolithicism is NOT based on ignorance and naivety.
Do you see what I mean by nuance? I think you just glanced at the comment, saw that there were negative words around rust, and you lossy compressed into "Rust bad".
No. Race conditions are a normal part of our world, in the same way it's not a memory error if you coded the discount feature so that people can apply more than one 10% off coupon to an order and as a result the nine different "10% off" offers that marketing seeded have summed to a 90% discount which bankrupts you.
An example race condition would be Mike and Sarah both wake up, notice there's no milk and decide to grab milk on the way home that evening, they both work a full day, drop past the store and arrive home with a carton of milk. But, now there are two cartons of milk, which is too much milk. Oops. This is called a "Time of Check versus Time of Use" race or ToCToU race.
(Safe) Rust does prevent Data Races which can be seen as a specific very weird type of Race Condition, unlike other race conditions a Data Race reflects a difference between how humans understand computers in order to write computer software and how the machine actually works.
Humans are used to experiencing a world in which things happen in order. We write software for that intuitive world, this is called "Sequential consistency". A happens before B, or B happens before A, one of these must be true. Mustn't it? But actually a modern multi-core CPU cannot afford sequential consistency, we give that up for more speed, so any appearance of sequential consistency in concurrent software is an illusion for our comfort. (Safe) Rust promises the illusion is maintained, if you try to shatter it the compiler is going to say "No", languages like C or C++ just say well, if you accidentally destroy the illusion your program might do absolutely anything at all, good luck with that.
I like your idea of illustrating a race condition with buying milk - that should become the default method of explaining them. (Either that or bartenders serving customers which is my usual method of understanding work queues)
It can be about any resource. You get it when two concurrent functions access the resource without a queue, atomic operation or wait, and one of them modifies it.
> (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.
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.
I love that cheeky "oh btw, there's also another vulnerability in rust coreutils rewrite, but we aren't talking about that" paragraph
That's because it's not a vulnerability per se. They found a way to use `rm` as a gadget for their privilege escalation.
The core problem is that there's a world-writable directory that is processed by a program running as root.
It's a race condition that can be used as a primitive to achieve privilege escalation which makes it legitimate but even if it you couldn't use it for anything else but to trick the system into acting on a directory it didn't meant to it would still be a valid vulnerability (regardless of the application).
Claiming it's not a valid bug would be similar to claiming an infoleak isn't as well when it's one of the building blocks of modern exploitation.
I'm not trying to be an ass, I'm just trying to add a bit of context to ensure that the implication is well understood.
But this vulnerability is enabled by a very creative exploitation of the complicated bind mounting scheme used by snap-confine. Just reading about these mounts between /usr/lib to /tmp and back triggered my sense of a potential security vulnerability.
Slightly tangential but I never ended up switching to nix (or guix) precisely because I don't fully understand the theory behind why things were done the way they were done and where the security boundaries are supposed to lie relative to a "regular" distro. I found plenty of prescriptive documentation giving me recipes to do anything I might be interested in doing but not much in the way of design documents explaining the system itself.
I never asked around so maybe that's on me. Debian works just fine though and containers are (usually) simple enough for me to wrap my head around.
I didn't end up using Flatpak for the same reason.
NixOS is incredibly complicated at build time, but the filesystem & runtime state is pretty simple. Run it in a VM and look around, there's very little magic at runtime; the trickery is mostly in the build time rpath hack to load shared libs from the specific /nix/store paths, and a lot of configuring software to read files from specific /nix/store paths.
When you sandbox your apps on debian already, there should be no security difference doing so on nixos, no?
The globally accessible /nix/store is frigthening, but read-only. Same applies to the nixos symlinks pointing there. This vulnerability was enabled by a writable /tmp and a root process reaching into it. This would be bad on debian and nixos.
I'm not suggesting the presence of a vulnerability just that I'm not comfortable switching to a complex system where I have little to no understanding of the logic behind the design. My remarks were nothing more than a tangential gripe.
This.
Might be worth updating the link.
I don't like snap and have always uninstalled it in the past. However, that gets more difficult in newer releases, so probably not a sustainable path. Still searching for the distro I could install instead of Xubuntu for friends and family who don't want or need the latest and greatest.
The main reason for my dislike is the closed source nature of snap distribution. App isolation is important and not easy. That bugs will happen and be fixed there is natural. Happens with every other system that was supposed to increase security, too.
Have you tried Debian with the XCFE desktop? Should be pretty similar to Xubuntu (but without Snap, of course)
I second Debian. All the good bits of Ubuntu have long since been ported back to Debian, and it has much more timely releases now.
Me too. Switching my home system from Ubuntu back to Debian was influenced a lot by snap. I don't get how they could fumble that one so hard. It goes against everything they used to stand for. If I want a bloated, slow, closed-source, proprietary app store with unclear security ramifications, I'll install MacOS or Windows. It also feels like app developers at least care a little bit about those stores. Mozilla for example still officially recommends installing their Debian package rather than through snap on Linux, despite shipping via snap by default on Ubuntu now.
Yes, Debian is great.
But there is also Arch by the way :)
Sure, I like Arch. Did not consider it for completely non-technical users, though.
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.
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 know Fedora, although haven't used it recently anymore because it's not approved at my current job.
But is that something to use by non-geeks on really low end machines?
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
They do document how to build and run, in the OS specific build docs. Eg this: https://github.com/canonical/multipass/blob/main/BUILD.linux...
I think pointing end users to use the end user packaged app is fine, as is to trust people who are comfortable with building from source to find the build docs from the repo.
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
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.
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?
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.
The mistake seems to be using a predictable path (/tmp/.snap) in a publicly-writable directory.
The exploit doesn't rely on the path being predictable though.
As I read it the .snap is expired and pruned, then the exploiter makes their own .snap in /tmp, then snap-confine assumes that the new .snap is the old one and executes with elevated privileges.
So, the path can be from mkstemp, or a sha-256 of your significant others fingerprint, it doesn't matter; until it expires it's plaintext in the /tmp listing.
{Wild, ignorant speculation follows ... hashing the inode and putting a signed file in the folder bearing that hash, then checking for that ... something that works but along those lines might be appropriate. (We know the inode for the 10 days we're waiting for /tmp/.snap to get pruned; time that might be used to generate a hash collision, so my off-the-cuff suggestion is definitely no good. It feels like there's a simple solution but everything I can think of fails to KPA, I think -- perhaps just use dm-crypt for the /tmp/.snap folder?}
Or just assert the UID and GID of /tmp/.snap before using. Of course, you'd want to open(2) /tmp/.snap and use fstat(2) on a descriptor (not just pass the path, /tmp/.snap, to stat(2)), then use mkdirat, openat & friends consistently.
Seems to address the proximal issue but perhaps leaves open use in a chaining attack?
Yes, it does. The attacker knows that snap is going to look in /tmp/.snap/, instead of e.g. /tmp/.snap.FjBz8oEWaU/ (which isn't guessable in advance) so when /tmp is flushed, he just has to recreate /tmp/.snap/ before snap-confine does, and drop his payload there.
If the directory had a random name, the attacker could see that name and recreate it after /tmp is flushed.
Only if you reuse the same random name. Which would be silly.
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.
The frustrating part is that Snap's confinement story was supposed to be a selling point. Here we are with a priv-esc in the daemon itself. At this point I've just disabled snapd on all our Ubuntu boxes and moved to flatpak or building from source. The attack surface of a privileged install daemon that parses arbitrary package manifests is just too broad.
The shared /tmp/ directory that can be used by processes of multiple users seems extremely prone to causing this type of issue. I wish there was a common convention for user-specific temp directories on Linux, because a whole class of vulnerabilities could go away.
MacOS handles this great by setting $TMPDIR to some /var/folders/.../ directory that's specific to the current user. Linux does have something similar with $XDG_RUNTIME_DIR (generally /run/user/$UID/), though it's stored in memory only which is a little different from usual for /tmp/, seemingly mainly intended for small stuff like unix sockets.
> 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 of course raises the question why the fuck snap doesn't use either of these mechanisms?
When will these distros accept suid was a mistake and disable it. It has lead to critical local privilege escalation exploits so many times.
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.
With https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.
> how many binaries are suid binaries while they probably shouldn't be (passwd
I would expect an unprivileged user to be able to change their own password. How else would that work?
Send a message to a socket-activated daemon running as a UID with write access to the password database.
Isn't the issue in this case caused not by suid, but by a daemon running as root reading files from a tmp dir? Seems like a socket-activated daemon wouldn't solve this specific case.
> How else would that work?
Windows way is to have a privileged service which the non-privileged user application talks to over sockets or similar.
systemd-homed stores most of the user specific information in the home directory `~/.identity`, but since the file contents have to be signed the changes need to be done though a daemon, which is talked to via IPC (homectl does the talking to systemd-homed).
> 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?
Run the part that needs root as a daemon, some server that accepts http requests
Use sudo and allow anyone to run the binary without password auth
Use the existing gamemode package
Those are a few options, of course it's your system in the end
First off, thanks very much for giving me exactly what I asked for.
You propose that instead of sometimes running ~five lines of C as root, I do one of the following:
1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in.
2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs.
3) Use a package that has several-thousand lines of C (and who knows how many lines of Python) running as root and does way more than I need.
All of these alternatives tell a story:
This is kinda my point. Some people rave about setuid programs and assert that they should not exist, but when you absolutely need to let an unprivileged user do things that only root is ordinarily permitted to do you're going to have to have code running as root. And when you have code running as root, you have to be careful to get it right. Whether it's running from a setuid root-owned executable, a persistent daemon running as root, or a regular program that sudo [1] has executed as root is irrelevant: it's all code running as root![0] People shit on sudo for both being setuid root and for being "too complicated". I love the hell out of the program; it's an essential part of how I get shit done on my PC. sudo is -very seriously- a great tool.
[1] ...or similar...
Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).
The systemd service executable is just your simple C program as-is.
Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.
I think the only thing that I find kinda strange about setuid/setgid is the fact that it is tied to an executable rather than as part of the executing principal.
As an example of an OS that doesn't use a concept, Windows only recently got Unix domain sockets (which is kinda the standard for IPC in *nix land) and generally used named pipes, mailslots, etc for IPC, which can be ACLed. Communication with services and elevation after Windows XP[1] was based on the the user's privileges and not "uid == 0" or "bit set on a file"
[1]: Before Vista, a lot of services actually straight up did show UIs on the desktop or whatnot. It was found though that doing this was pretty bad as you could use automation tools to drive the UI and it could lead to some pretty nasty local privilege escalations.
> it's all code running as root!
Yup! There's no way around that if in the end you need elevated privileges somewhere.
What the other options allow is to contain the blast radius. With the daemon you can control access via groups on the socket, and with sudo you can control access via sudoers.d
> and who knows how many lines of Python
There's no python in gamemode...
> There's no python in gamemode...
...huh. There isn't. I checked out the git repo, and read the contents of the daemon directory. I guess I looked at the meson stuff at top level and thought to myself "Meson? Isn't that one of the half-billion Python build systems?" [0] and -from that thought- assumed that there was some Python in the directories I didn't examine. (It turns out that there is not. It's all C and configuration.)
> What the other options allow is to contain the blast radius.
I can do that by removing the "other" executable bit, adding the group executable bit, and setting the file's group appropriately to control access. You are limited to a single group, but it's not like you're unable to "contain the blast radius".
> With the daemon you can control access via groups on the socket...
As long as it's a UNIX socket, yes. (Getting guaranteed information about the identity of the process on the other side of such a socket is one of my favorite things about them.)
> Yup! There's no way around that if in the end you need elevated privileges somewhere.
Exactly. I hope the "setuid is evil and shouldn't exist" people who are complaining in good faith are capable of both realizing this and also recognizing that "just daemonize it" and "just run it with sudo" are -at times- not obviously the right thing to do.
[0] It's not!
>1)
Building services should be easy. The fact that Linux does not have an easy to use IPC mechanism is the fault of Linux. Yes, systemd can make it so services don't have to run until they are connected, and yes dbus exists, but it's overcomplicated for something which should be easy to make. This is a Linux devex failure.
>2)
I agree this is going in the wrong direction. Full sudo is also even more in the wrong direction away from only giving the minimal amount of privileges to the code that needs it.
>3)
See my response to 1). Making programs with different capabilities able to talk to each other should be made dead easy to do.
> The fact that Linux does not have an easy to use IPC mechanism...
What? Send bytes down a UNIX socket. There's nothing easier, really. It's so simple, it's what systemd uses to have monitored daemons indicate that they're now actually running.
The rest of your commentary has nothing to do with my commentary about unprivved users running code as root. Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
>There's nothing easier, really. It's so simple
It really isn't. You have to a whole protocol on top of it if you want to use it and then build out the daemon logic yourself. If it was so easy why didn't you write it instead of making a suid binary. The complexity is not sufficiently abstracted away.
>Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
My whole response was addressing the core of your argument in your post "The alternative to running ~five lines of C as root is to run many more lines as root." The reason it's many more lines is because the Linux developers did not write abstractions to make it simple to do. If you read my original post in this comment chain you will see that I do have problems with setuid executables and want distros to disable them.
> 1) Run a persistent whole-ass daemon using something for IPC
This is the recommended way on Windows as well. Have the (privileged) installer install a privileged service, and have the non-privileged user program communicate with it.
> This is the recommended way on Windows as well.
Quite possibly because there are something like two people on earth who understand the Impersonation machinery [0] and one of the two is likely to cause an HN Black Banner Event any day now... so there's no real 'sudo' or 'setuid' equivalent on NT. ;)
[0] Seriously, it's fucking complicated. Decades ago, I wanted to write a sudo for the then-$DAYJOB. I gave up after a week when I couldn't even get the Impersonation equivalent of "Hello world" to work.
In general, I think it's because it tends to be an XY problem. If you're on a service account or something, you generally have SeBackupPrivilege (override read ACLs) and SeRestorePrivilege (override write ACLs) and other relevant privileges so like if you're changing files that's less needed since you can overwrite the ACLs to the necessary files as needed
1) I believe the current iteration you have of it is safe.
2) I suggest that a service is created for managing system performance that exposes an API to your user to turn on and off game mode.
My commentary here [0] directly relates to your #2.
[0] <https://news.ycombinator.com/item?id=47436085>
Around 20 years after suid is deprecated.
systemd-tmpfiles bugs the heck out of me. It breaks so many applications for absolutely no good reason. A typical system of mine not running it gathers less than 1GiB per year of uptime in /tmp with disk sizes measured in TB. Even if you are /tmp on a 256GB NVME, that's less than 1% of your total disk per year of uptime. If you upgrade to alternating Ubuntu LTS editions (which requires a reboot every 4 years) systemd-tmpfiles will save you a maximum of 4GB of disk space.
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.
>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.
I always wonder why Ubuntu is even on the radar anymore. It is a pile of questionable decisions with a billionaire ego bus factor. If you like apt, just use Debian. sid is fine for desktops if you are moderately technical.
>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).
Except their LTS is a lie or maybe plausible deniability for businesses that DGAF. They have no idea what they are doing with backports and lack thereof. And if you aren't paying you aren't even receiving many of the updates.
> And if you aren't paying you aren't even receiving many of the updates.
Are you sure you didn't mean RedHat? Last I checked there's no requirement to pay anything in order to use an LTS release of Ubuntu. Even if you go with Pro to get those extra years of Extended Support (to make it ~12 years?) you still get up to 5 licenses for personal use. No money asked, no *BS* subscription model. Isn't that more than enough any non-commercial user?
Read https://ubuntu.com/security/esm carefully. The chance of running everything out of 'main' is close to zero. I am shocked by how little people understand this.
Main is all you need to set up a working system and deploy services. Much like BaseOS in RHEL you get full support for those packages for 5+5 years. With snaps you effectively get rolling releases of LXD, microk8s, openstack, docker and other relevant things. What else do you need? Seriously, how come this isn't enough for a non commercial user?
Because this is Stockholm syndrome, better community options prevail, main is not all people deploy and is not the only repo default enabled. openstack, docker are legacy tech, never encountered anyone using LXD or microk8s thankfully I'll steer clear of that snap garbage barge.
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 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.
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.
Most of our servers are Debian (well, mine are Devuan) but there are a few that have to be Ubuntu or Redhat for official support of COTS.
Of those choices, I prefer Ubuntu as being closer to the Debian/Devuan ones.
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.
Why does snap-confine need to be setuid, rather than use a user namespace?
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]
Well, fuck snaps, that is.
Even though I've used ubuntu since 6.04, fuck snaps. I'm still stuck on Ubuntu even after 20 years. But fuck snaps.
Why are you stuck on Ubuntu, what is holding you back?
Eh. Definitely not great but until they make it so you can't trivially MitM sudo, I don't think any local privilege execution bugs on Linux are especially notable, at least for most desktop users. Also there's the whole xkcd "at least they can't install drivers" thing.
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
[flagged]
[flagged]
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...
The best discussion I can find for the official reasons for switching is https://discourse.ubuntu.com/t/carefully-but-purposefully-ox... -
> But… why?
> Performance is a frequently cited rationale for “Rewrite it in Rust” projects. While performance is high on my list of priorities, it’s not the primary driver behind this change. These utilities are at the heart of the distribution - and it’s the enhanced resilience and safety that is more easily achieved with Rust ports that are most attractive to me.
> The Rust language, its type system and its borrow checker (and its community!) work together to encourage developers to write safe, sound, resilient software. With added safety comes an increase in security guarantees, and with an increase in security comes an increase in overall resilience of the system - and where better to start than with the foundational tools that build the distribution?
So yes, it sounds like the primary official reason is "enhanced resilience and safety". Given that, I would be interested in seeing the number of security problems in each implementation over time. GNU coreutils does have problems from time to time, but... https://app.opencve.io/cve/?product=coreutils&vendor=gnu only seems to list 10 CVEs since 2005. Unfortunately I can't find an equivalent for uutils, but just from news coverage I'm pretty sure they have a worse track record thus far.
> But… why?
> Performance is a frequently cited rationale for “Rewrite it in Rust” projects.
Rewrite from what? Python/Perl? If the original code is in C there _might_ be a performance gain (particularly if it was poorly written to begin with), but I wouldn't expect wonders.
probably because many of those tools were around for 20ish years before 2005
Could be. The thing is, it kinda doesn't matter; what matters is, what will result in the least bugs/vulnerabilities now? To which I argue the answer is, keeping GNU coreutils. I don't care that they have a head start, I care that they're ahead.
That's short sighted. The least number of bugs now isn't the only thing that matters. What about in 5 years from now? 10 years? That matters too.
To me it seems inarguable that eventually uutils will have fewer bugs than coreutils, and also making uutils the default will clearly accelerate that. So I don't think it's so easy to dismiss.
I think they were probably still a little premature, but not by much. I'd probably have waited one more release.
>>> I don't care that they have a head start, I care that they're ahead.
Nice
fileutils-1.0 was released in 1990 [1]. shellutils-1.0 was released in 1991 [2], and textutils-1.0 was released a month later in the same year [3].
Those three packages were combined into coreutils-5.0 in 2003 [4].
[1] https://groups.google.com/g/gnu.utils.bug/c/CviP42X_hCY/m/Ys... [2] https://groups.google.com/g/gnu.utils.bug/c/xpTRtuFpNQc/m/mR... [3] https://groups.google.com/g/gnu.utils.bug/c/iN5KuoJYRhU/m/V_... [4] https://lists.gnu.org/archive/html/info-gnu/2003-04/msg00000...
It's extremely early to say if things are rushed or not. It's unsurprising that newer software has an influx of vulnerabilities initially, it'll be a matter of retrospectively evaluating this after that time period has passed.
> influx of vulnerabilities initially
https://en.wikipedia.org/wiki/Bathtub_curve
It's a little different with software since you don't usually have the code or silicon wearing out, but aging software does start to have a mismatch with the way people are trying to use it and the things it has to interact with, which leads to a similar rise of "failure" in the end.
It's not even about API boundaries, it's about logic and the language isn't really responsible for that.
Expecting it to prevent it would be as gullible as expecting it to prevent a toctou or any other type of non trivial vulnerability.
That's why even though I appreciate the role of these slightly safer languages I still have a bit of a knee-jerk reaction to the exagerated claims of their benefits and how much of a piece of crap C is.
Spoiler, crappy programmers write crappy code regardless of the language so maybe we should focus on teaching students to think of the code they're writing from a different perspective and focus safety and maintainability rather than "flashiness"
[flagged]
Yeah we get it you don't like rust and you want everyone to know how weird you are by tearing down asinine arguments no one actually made. How boring.
[flagged]
> based on ignorance and naivety.
About as nuanced as your bait framing of what a mere language ought/can do. Oh you're a python backend developer, guess that explains it.
So I was saying that rust monolithicism is NOT based on ignorance and naivety.
Do you see what I mean by nuance? I think you just glanced at the comment, saw that there were negative words around rust, and you lossy compressed into "Rust bad".
Your post is very badly written. It's confusing and starts off with a totally weird comment about wasting revolutionary capacity. Expect downvotes.
Rewrite tools in new language, get new exciting bugs!
That's optimistic. Use a search engine to find:
Very good point
Is a race condition a memory related error?
Not this particular kind. This is a race between separate processes, and the target is the file system, not a location in memory.
No. Race conditions are a normal part of our world, in the same way it's not a memory error if you coded the discount feature so that people can apply more than one 10% off coupon to an order and as a result the nine different "10% off" offers that marketing seeded have summed to a 90% discount which bankrupts you.
An example race condition would be Mike and Sarah both wake up, notice there's no milk and decide to grab milk on the way home that evening, they both work a full day, drop past the store and arrive home with a carton of milk. But, now there are two cartons of milk, which is too much milk. Oops. This is called a "Time of Check versus Time of Use" race or ToCToU race.
(Safe) Rust does prevent Data Races which can be seen as a specific very weird type of Race Condition, unlike other race conditions a Data Race reflects a difference between how humans understand computers in order to write computer software and how the machine actually works.
Humans are used to experiencing a world in which things happen in order. We write software for that intuitive world, this is called "Sequential consistency". A happens before B, or B happens before A, one of these must be true. Mustn't it? But actually a modern multi-core CPU cannot afford sequential consistency, we give that up for more speed, so any appearance of sequential consistency in concurrent software is an illusion for our comfort. (Safe) Rust promises the illusion is maintained, if you try to shatter it the compiler is going to say "No", languages like C or C++ just say well, if you accidentally destroy the illusion your program might do absolutely anything at all, good luck with that.
I like your idea of illustrating a race condition with buying milk - that should become the default method of explaining them. (Either that or bartenders serving customers which is my usual method of understanding work queues)
It can be about any resource. You get it when two concurrent functions access the resource without a queue, atomic operation or wait, and one of them modifies it.
> (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.