| ▲ | wahern 5 hours ago |
| > What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing They knew how to write Rust, but clearly weren't sufficiently experienced with Unix APIs, semantics, and pitfalls. Most of those mistakes are exceedingly amateur from the perspective of long-time GNU coreutils (or BSD or Solaris base) developers, issues that were identified and largely hashed out decades ago, notwithstanding the continued long tail of fixes--mostly just a trickle these days--to the old codebases. |
|
| ▲ | concinds an hour ago | parent | next [-] |
| Reading that Canonical thread was jaw-dropping. Paraphrased: "Rust is more secure, security is our priority, therefore deploying this full-rewrite of core utils is an emergency. If things break that's fine, we'll fix it :)". I would not want to run any code on my machines made by people who think like this. And I'm pro-Rust. Rust is only "more secure" all else being equal. But all else is not equal. A rewrite necessarily has orders of magnitude more bugs and vulnerabilities than a decades-old well-maintained codebase, so the security argument was only valid for a long-term transition, not a rushed one. And the people downplaying user impact post-rollout, arguing that "this is how we'll surface bugs", and "the old coreutils didn't have proper test cases anyway" are so irresponsible. Users are not lab rats. Maintainers have a moral responsibility to not harm users' systems' reliability (I know that's a minority opinion these days). Their reasoning was flawed, and their values were wrong. |
|
| ▲ | nine_k 5 hours ago | parent | prev | next [-] |
| More than that: it seems that Rust stdlib nudges the developer towards using neat APIs at an incorrect level of abstraction, like path-based instead of handle-based file operations. I hope I'm wrong. |
| |
| ▲ | NobodyNada 4 hours ago | parent | next [-] | | Nearly every available filesystem API in Rust's stdlib maps one-to-one with a Unix syscall (see Rust's std::fs module [0] for reference -- for example, the `File` struct is just a wrapper around a file descriptor, and its associated methods are essentially just the syscalls you can perform on file descriptors). The only exceptions are a few helper functions like `read_to_string` or `create_dir_all` that perform slightly higher-level operations. And, yeah, the Unix syscalls are very prone to mistakes like this. For example, Unix's `rename` syscall takes two paths as arguments; you can't rename a file by handle; and so Rust has a `rename` function that takes two paths rather than an associated function on a `File`. Rust exposes path-based APIs where Unix exposes path-based APIs, and file-handle-based APIs where Unix exposes file-handle-based APIs. So I agree that Rust's stdilb is somewhat mistake prone; not so much because it's being opinionated and "nudg[ing] the developer towards using neat APIs", but because it's so low-level that it's not offering much "safety" in filesystem access over raw syscalls beyond ensuring that you didn't write a buffer overflow. [0]: https://doc.rust-lang.org/std/fs/index.html | | |
| ▲ | juergbi 32 minutes ago | parent | next [-] | | > So I agree that Rust's stdilb is somewhat mistake prone; not so much because it's being opinionated and "nudg[ing] the developer towards using neat APIs", but because it's so low-level that it's not offering much "safety" in filesystem access over raw syscalls beyond ensuring that you didn't write a buffer overflow. `openat()` and the other `*at()` syscalls are also raw syscalls, which Rust's stdlib chose not to expose. While I can understand that this may not be straight forward for a cross-platform API, I have to disagree with your statement that Rust's stdlib is mistake prone because it's so low-level. It's more mistake prone than POSIX (in some aspects) because it is missing a whole family of low-level syscalls. | |
| ▲ | masklinn 2 hours ago | parent | prev [-] | | > For example, Unix's `rename` syscall takes two paths as arguments; you can't rename a file by handle And then there’s renameat(2) which takes two dirfd… and two paths from there, which mostly has all the same issues rename(2) does (and does not even take flags so even O_NOFOLLOW is not available). I’m not sure what you’d need to make a safe renameat(), maybe a triplet of (dirfd, filefd, name[1]) from the source, (dirfd, name) from the target, and some sort of flag to indicate whether it is allowed to create, overwrite, or both. As the recent https://blog.sebastianwick.net/posts/how-hard-is-it-to-open-... talks about (just for file but it applies to everything) secure file system interaction is absolutely heinous. [1]: not path | | |
| ▲ | mort96 2 hours ago | parent [-] | | How about fd of the file you wanna rename, dirfd of the directory you want to open it in, and name of the new file? You could then represent a "rename within the same directory" as: dfd = opendir(...); fd = openat(dfd, "a"); rename2(fd, dfd, "b"); I can't think of a case this API doesn't cover, but maybe there is one. | | |
| ▲ | masklinn an hour ago | parent [-] | | The file may have been renamed or deleted since the fd was opened, and it might have been legitimate and on purpose, but there’s no way to tell what trying to resolve the fd back to a path will give you. And you need to do that because nothing precludes having multiple entries to the same inode in the same directory, so you need to know specifically what the source direntry is, and a direntry is just a name in the directory file. |
|
|
| |
| ▲ | JuniperMesos 3 hours ago | parent | prev | next [-] | | After reading this article, I'm inclined to think that the right thing for this project to do is write their own library that wraps the Rust stdlib with a file-handle-based API along with one method to get a file handle from a Path; rewrite the code to use that library rather than rust stdlib methods, and then add a lint check that guards against any use of the Rust standard library file methods anywhere outside of that wrapper. | | |
| ▲ | dbdr 2 hours ago | parent [-] | | If that's the right approach, then it would be useful to make that library public as a crate, because writing such hardened code is generally useful. Possibly as a step before inclusion in the rust stdlib itself. |
| |
| ▲ | jeroenhd 3 hours ago | parent | prev [-] | | If anything, I find the rust standard library to default to Unix too much for a generic programming language. You need to think very Unixy if you want to program Rust on Windows, unless you're directly importing the Windows crate and foregoing the Rust standard library. If you're writing COBOL style mainframe programs, things become even more forced, though I doubt the overlap between Rust programmers and mainframe programmers that don't use a Unix-like is vanishingly small. This can also be a pain on microcontrollers sometimes, but there you're free to pretend you're on Unix if you want to. |
|
|
| ▲ | AlotOfReading 5 hours ago | parent | prev | next [-] |
| Someone once coined a related term, "disassembler rage". It's the idea that every mistake looks amateur when examined closely enough. Comes from people sitting in a disassembler and raging the high level programmers who had the gall to e.g. use conditionals instead of a switch statement inside a function call a hundred frames deep. We're looking solely at the few things they got wrong, and not the thousands of correct lines around them. |
| |
| ▲ | Cthulhu_ 9 minutes ago | parent | next [-] | | Thing is, these tools are so critical that even one error may cause systems to be compromised; rewriting them should never be taken lightly. (Actually ideally there's formal verification tools that can accurately test for all of the issues found in this review / audit, like the very timing specific path changes, but that's a codebase on its own) | |
| ▲ | irishcoffee 4 hours ago | parent | prev [-] | | When I read the article I came away with the impression that shipping bugs this severe in a rewrite of utils used by hundreds of millions of people daily (hourly?) isn’t ok. I don’t think brushing the bad parts off with “most of the code was really good!” is a fair way to look at this. Cloudflare crashed a chunk of the internet with a rust app a month or so ago, deploying a bad config file iirc. Rust isn’t a panacea, it’s a programming language. It’s ok that it’s flawed, all languages are. | | |
| ▲ | gmueckl 4 hours ago | parent | next [-] | | I think that legitimate real world issues in rust code should be talked about more often. Right now the language enjoys a reputation that is essentiaöly misleading marketing. It isn't possible to create a programing language that doesn't allow bugs to happen (even with formal verification you can still prove correctness based on a wrong set of assumptions). This weird, kind of religious belief that rust leads to magically completely bug free programs needs to be countered and brought in touch with reality IMO. | | |
| ▲ | jeroenhd 3 hours ago | parent | next [-] | | Nobody believes Rust programs are but free, though. Rust never promised that. It doesn't even promise memory safety, it only promises memory safety if you restrict yourself to safe APIs which simply isn't always possible. | | |
| ▲ | Galanwe 2 hours ago | parent [-] | | > it only promises memory safety if you restrict yourself to safe APIs which simply isn't always possible. Less than that actually, considering Rust has its own definition of what "safe" means. | | |
| |
| ▲ | testdelacc1 3 hours ago | parent | prev [-] | | Is it possible you’ve misunderstood what Rust promises? > It isn't possible to create a programing language that doesn't allow bugs to happen Yes, that’s true. No one doubts this. Except you seem to think that Rust promises no bugs at all? I don’t know where you got this impression from, but it is incorrect. Rust promises that certain kinds of bugs like use-after-free are much, much less likely. It eliminates some kinds of bugs, not all bugs altogether. It’s possible that you’ve read the claim on kinds of bugs, and misinterpreted it as all bugs. I’ve had this conversation before, and it usually ends like https://www.smbc-comics.com/comic/aaaah |
| |
| ▲ | lelanthran 3 hours ago | parent | prev | next [-] | | I find it hilarious that this comment is being downvoted. Exactly what is the controversial take here? > I don’t think brushing the bad parts off with “most of the code was really good!” is a fair way to look at this. Nope. this is fine. > Cloudflare crashed a chunk of the internet with a rust app a month or so ago, deploying a bad config file iirc. Maybe this? > Rust isn’t a panacea, it’s a programming language. It’s ok that it’s flawed, all languages are. Nope, this is fine too. | | |
| ▲ | dbdr 2 hours ago | parent | next [-] | | I didn't downvote, but I feel the last two points show a lack of nuance. It's saying "Rust doesn't prevent 100% of the bugs, like all other programming languages", while failing to acknowledge that if a programming language prevents entire classes of bugs, it's a very significant improvement. | |
| ▲ | huimang 2 hours ago | parent | prev [-] | | Because the bugs were caused by programmer error, not anything inherent to rust. It was more notable due to cloudflare being a critical dependency for half the internet, but that particular issue could've happened in any language. This kind of melodramatic reaction to rust code is fatiguing, honestly. Rust does not bill itself as some programming panacea or as a bug free language, and neither do any of the people I know using it. That's a strawman that just won't go away. Rust applies constraints regarding memory use and that nearly eliminates a class of bugs, provided safe usage. And that's compelling to enough people that it warrants migration from other languages that don't focus on memory safety. Bugs introduced during a rewrite aren't notable. It happens, they get fixed, life moves on. |
| |
| ▲ | fluffybucktsnek 2 hours ago | parent | prev [-] | | If I'm not mistaken, in the Cloudflare case, both the Rust rewrite and the C++ original version crashed. The primary cause being the bad config file. |
|
|
|
| ▲ | slopinthebag 4 hours ago | parent | prev | next [-] |
| Seems pretty impressive they rewrote the coreutils in a new language, with so little Unix experience, and managed to do such a good job with very little bugs or vulns. I would have expected an order of magnitude more at least. Shows how good Rust is, that even inexperienced Unix devs can write stuff like this and make almost no mistakes. |
| |
| ▲ | nine_k 4 hours ago | parent | next [-] | | Yes, it's the lack of Unix experience that's terrifying. So many of mistakes listed are rookie mistakes, like not propagating the most severe errors, or the `kill -1` thing. Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils? | | |
| ▲ | aw1621107 4 hours ago | parent | next [-] | | > Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils? From what I understand, "assigned" probably isn't the best way to put it. uutils started off back in 2013 as a way to learn Rust [0] way before the present kerfuffle. [0]: https://github.com/uutils/coreutils/tree/9653ed81a2fbf393f42... | | |
| ▲ | nineteen999 3 hours ago | parent | next [-] | | Yeah perhaps learning UNIX API's and Rust at the same time doesn't lead to a drop in replacement ready to be shipped in major distributions. Who whould have thunk it. | | |
| ▲ | aw1621107 2 minutes ago | parent [-] | | Strictly speaking it doesn't preclude eventually producing a production-ready drop-in replacement either, though evidently that needs a fresh set of eyes. |
| |
| ▲ | bpbp-mango 3 hours ago | parent | prev [-] | | exactly this. I wrote one of them back then as a learning experience. some of the code I wrote is still intact, incredibly. |
| |
| ▲ | JuniperMesos 3 hours ago | parent | prev [-] | | Why is it even possible to represent a negative PID, let alone treat the integer -1 as a PID meaning "all effective processes"? This seems like a mistake (if not a rookie mistake) in the Linux kernel API itself. | | |
| ▲ | nine_k 2 hours ago | parent | next [-] | | -1 is a special case, a way to represent a PID with all bits set in a platform-independent way. It's not very clean, and it comes from ancient times when writing some extra code and storing an extra few bytes was way more expensive. | |
| ▲ | dminik 2 hours ago | parent | prev | next [-] | | It feels a bit like a "better is better" language hitting all of the quirks of a "worse is better" environment. | |
| ▲ | antonvs 2 hours ago | parent | prev [-] | | Pretty much all the rough edges being discussed here are design mistakes in Linux or Unix, and/or a consequence of using an unsafe language with limited abstractions and a weak type system. But because of ubiquity, this is everyone’s problem now. |
|
| |
| ▲ | gblargg 2 hours ago | parent | prev | next [-] | | Rewriting perfectly good code was a colossal mistake. | | |
| ▲ | Cthulhu_ 3 minutes ago | parent [-] | | Not necessarily, but was the reasoning sound and have the tradeoffs been made? The website (https://uutils.github.io/) shows some reasonable "why"s (although I disagree with making "Rust is more appealing" a compelling reason, but that's just me (disclaimer: I don't like C and don't know Rust so take this comment as you will)), but I think what's missing is how they will ensure both compatibility and security / edge case handling, which requires deep knowledge and experience in the original code and "tribal knowledge" of deep *nix internals. |
| |
| ▲ | twhitmore 2 hours ago | parent | prev [-] | | [flagged] |
|
|
| ▲ | pando85 3 hours ago | parent | prev [-] |
| Memory safety catches buffer overflows. CI catches logic bugs. Neither catches the Unix API gotchas nobody documented. |
| |
