Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bugs Rust won't catch

corrode.dev

Post reply on HN
Print view View original

191–200 of 395 posts

Re: Bugs Rust won't catch

#191

Post by geocar »

justincormack wrote: post #102
misja111 wrote: post #59

The root cause of some of the bugs seems to be the opaque nature of some of the Unix API. E.g. > The trap is that get_user_by_name ends up loading shared libraries from the new root filesystem to resolve the username. An attacker who can plant a file in the chroot gets to run code as uid 0. To me such a get_user_by_name function is like a booby trap, an accident that is waiting to happen. You need to have user data,…

Yes thats one thing Musl libc removes.

If the attacker can control newroot/etc/passwd they _still_ get getpwnam to return whatever userid they want. The solution is to not lookup --userspec=username:group inside the chrooted-space, but from outside.

Also, hi how's things? :)

Re: Bugs Rust won't catch

#192

Post by pdpi »

bcjdjsndon wrote: post #175
kibwen wrote: post #115

Earlier quoted context omitted.

Indeed, and it doesn't need to be deprecated, because it's an API explicitly designed to give you low-level control where you need it, and because it is appropriately defined as an `unsafe` function with documented safety invariants that must be manually upheld in order for usage to be memory-safe. The documentation also suggests several other (safe) functions that should be used instead when possible, and provides c…

> and because it is appropriately defined as an `unsafe` function with documented safety invariants that must be manually upheld in order for usage to be memory-safe. Didn't we learn from c, and the entire raison detre for rust, is that coders cannot be trusted to follow rules like this? If coders could "(document) safety invariants that must be manually upheld in order for usage to be memory-safe." there's be no nee…

The issue with C is that every single use of a pointer needs to come with safety invariants (at its most basic: when you a pass a pointer to my function, do I. take ownership of your pointer or not?). You cannot legitimately expect people to be that alert 100% of the time.

Inversely, you can write whole applications in rust without ever touching `unsafe` directly, so that keyword by itself signals the need for attention (both to the programmer and the reviewer or auditor). An unsafe block without a safety comment next to it is a very easy red flag to catch.

Re: Bugs Rust won't catch

#193

Post by dwattttt »

lionkor wrote: post #120

I struggle to find anything on this post that wouldn't be caught by some kind of unit test or manual review, especially when comparing with the GNU source for the coreutils. The whole coreutils rewrite is a terrible idea[1] and clearly being done in the wrong way (without the knowledge gained from the previous software). If you do a rewrite, you should fully understand and learn from the predecessor, otherwise youre…

> I struggle to find anything on this post that wouldn't be caught by some kind of unit test or manual review, especially when comparing with the GNU source for the coreutils.

> If you do a rewrite, you should fully understand and learn from the predecessor, otherwise youre bound to repeat all the mistakes. Embarassing.

Interestingly, the uutils project uses the GNU coreutils test suite.

EDITED to add: they also have a stated position of not allowing contributions based on reading the GPL'd source.

Re: Bugs Rust won't catch

#194

Post by irishcoffee »

gzread wrote: post #183
huimang wrote: post #176

Earlier quoted context omitted.

I'm neither praising or admonishing rust. Did you read the parent comment or its parents' comment I was responding to at all? (grandparent comment): "Cloudflare crashed a chunk of the internet with a rust app a month or so ago" The actual bug had nothing to do with rust, yet rust is specifically brought up here. (grandparent comment): "Rust isn’t a panacea, it’s a programming language. It’s ok that it’s flawed, all l…

The cloudflare bug was the equivalent of an uncaught exception caused by a malformed config file. There's no recovery from a malformed config file - the software couldn't possibly have done its job. What's salient is that they were using an alternative to exceptions, because people were told exceptions were error-prone, and using this thing instead would make it easier to write bug-free code. But don't do the equival…

That was why I brought it up. I wasn't trying to be snarky or haughty. Thank you for filling in the gaps, I should have done that instead of the 1-liner.

Re: Bugs Rust won't catch

#195

Post by satvikpendem »

Unrelated but also in the category of bugs Rust won't catch (natively), there are crates that allow C++ style contracts, or more generally, dependent typing and can be used to catch issues at compile time rather than runtime. I use this one, anodized.

https://docs.rs/anodized/latest/anodized/

Re: Bugs Rust won't catch

#196

Post by jimmypk »

collinfunk wrote: post #6

Hi, I am one of the maintainers of GNU Coreutils. Thanks for the article, it covers some interesting topics. In the little Rust that I have used, I have felt that it is far too easy to write TOCTOU races using std::fs. I hope the standard library gets an API similar to openat eventually. I just want to mention that I disagree with the section titled "Rule: Resolve Paths Before Comparing Them". Generally, it is better…

[flagged]

Re: Bugs Rust won't catch

#197

Post by geocar »

alkonaut wrote: post #78

> What’s notable is that all of these bugs landed in a production Rust codebase, written by people who knew what they were doing So does this mean that neither did the original utils have any test harness, the process of rewriting them didn't start by creating one either? Sure there are many edge cases, but surely the OS and FS can just be abstracted away and you can verify that "rm .//" actually ends up doing what i…

> So does this mean that neither did the original utils have any test harness, the process of rewriting them didn't start by creating one either?

Yes.

> Sure there are many edge cases, but surely the OS and FS can just be abstracted away and you can verify that "rm .//" actually ends up doing what is expected (Such as not deleting the current directory)?

I think people have been trying that since before I was born and haven't yet been successful, so I am much less sure than you are.

For example: How do you decide how many `/` characters to try?

For a better one: Can you imagine if "rm" could simply decide to refuse to delete files containing "important" as first 9 bytes? How would you think of a test for something like that without knowing the letters in that order? What if the magic word wasn't in a dictionary?

> This doesn't seem like sloppy coding, nor a critique of the language, it's just the same old "Oh, this is systems programming, we don't do tests"?

I've never heard anyone say that except as a straw man.

I've heard people say tests don't do what people think they do.

Re: Bugs Rust won't catch

#198

Post by osmsucks »

aw1621107 wrote: post #127
osmsucks wrote: post #100

I feel like one of the takeaways here is that Rust protects your code as long as what your code is doing stays predictably in-process. Touching the filesystem is always ripe with runtime failures that your programming language just can't protect you from. (Or maybe it also suggests the `std::fs` API needs to be reworked to make some of these occurrences, if not impossible, at least harder.) On a separate note: I have…

> and I'm striving to keep it 100% Zig with no libc calls anywhere. Which may or may not turn out to be possible, we'll see. Probably will depend on what platform(s) you're targeting and/or your appetite for dealing with breakage. You can avoid libc on Linux due to its stable syscall interface, but that's not necessarily an option on other platforms. macOS, for instance, can and does break syscall compatibility and r…

Since it's a personal project, Linux compatibility is the only thing I care about right now. I'm testing it under WINE as well, just because I can, but I don't have access to Mac OS so I'm skipping that problem entirely for now
Post reply on HN