This is a useful tip!

but also... who has a dir with 777 permissions? Is that something people do nowadays?

My guess would be mounting an NTFS partition - with ntfs-3g it will load everything as 777 just by default, since it can’t translate the permissions.

I've seen users who have every file set to 777. They do it to "avoid permissions issues"

Heh I can remember doing that, in the distant past.

Well, everybody has 1777 as /tmp (with the sticky bit).

  $ ll -d /tmp
  drwxrwxrwt. 20 root root 4096 Mar  3 12:19 /tmp
  $ mkdir mytmp
  $ chmod 1777 mytmp
  $ ll -d mytmp
  drwxrwxrwt. 1 luser lgroup 0 Mar  3 12:19 mytmp

Well, maybe not everybody

  $ ls -ld /tmp
  drwxrwx--x. 2 shell shell 40 Jan 15  2022 /tmp

edit: sorry, I should have added this is termux :)

check further down this discussion for immediately downvoted comments

https://news.ycombinator.com/item?id=47191837 https://news.ycombinator.com/item?id=47191619

Post anything negative about rust, or anything about a severe bug in some non-rust code, for examples of your own

I have nothing against rust, although the learning curve is too steep and development in rust is too slow to be a practical general purpose language for a regular company.

The culture around dependencies also means you pay for your memory safety by increased supply chain risk.

Golang or Java gets you memory safety, faster compilation, easy hiring and have better standard libraries

I completely agree with your criticisms. I've been saying many of the same things about rust for years on HN. But I'm rarely downvoted for saying so.

FWIW, I also really like rust. I personally much prefer it over Go and Java. But those are still very legitimate criticisms.

> You may have never written a memory bug in your life, but I have, and that renders me completely incompetent.

This feels overly binary. Memory management bugs is just one class of bugs, and there have been many other bugs leading to security issues or defects.

If you apply the standard "has ever written a bug" → "completely incompetent" you will have to stop using software, and if you think about it most other technology too

Memory safety is a very useful trait for a language though, and as you say provided by a whole bunch of different languages nowadays

Even the statement that (100% safe) Rust does not have memory bugs/mutable aliasing is not always true.

It's well known that Rust has difficulty representing graph-like memory structures, and people have taken to using arrays of `Node`-s to represent graphs, where each graph edge represents a pointer to another node.

This both efficient, and fast, but this approach sidesteps the borrow checker.

If you had a method that 2 mutable `Node` references as parameters, the borrow checker would complain if they'd point to the same struct. If you pass 2 ints, it won't.

Likewise, since liveness is tracked by user logic, you can refer to stale, deallocated `Node`-s or ones that haven't been initialized yet.

I've had people argue this is not a true memory bug, since you're not causing 'real' memory faults, but in C, `malloc` is just a function that hands you pointers into chunks of pre-allocated memory space most of the time, when it doesn't have to ask the OS for more.

I know from experience some people see this criticism as an attack on their favourite language and instantly rebuke it.

But I'd like to argue that there's something there, and it bears thinking about how 'memory allocation exisitng outside Rust' and 'memory allocating existing inside Rust' behave differently might be seen as an interesting dicothomy that needs to be resolved and that resolution might improve Rust's (or some successor language's) memory model.

The difference is the checking, and actual enforcement of it.

Go and use get_unchecked if you want to and get C like behavior. But the safety note tells you the potential issues:

Safety

Calling this method with an out-of-bounds index is undefined behavior even if the resulting reference is not used.

You can think of this like .get(index).unwrap_unchecked(). It’s UB to call .get_unchecked(len), even if you immediately convert to a pointer. And it’s UB to call .get_unchecked(..len + 1), .get_unchecked(..=len), or similar.

https://doc.rust-lang.org/std/vec/struct.Vec.html

> Memory management bugs is just one class of bugs

It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.

That's why memory bug severity is often "MAY lead to RCE but who knows". At least with non-UB bugs you can reason about them.

In any case, Rust massively helps with logic bugs too. It's not just about memory safety.

> It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.

This is also why memory safety is table-stakes when it comes to formal verification of the underlying program logic. You can't solve logic bugs (even where that's known to be feasible, such as for tightly self-contained, library-like features) without solving memory safety first.

> it always leads to UB, which means you can't say anything about what happens next.

If you read a language standard and try very hard to forget that the actual computer exists, sure.

If you remember computers are real, you can pretty easily tell what will happen when you write to address 0x00000000 on a CPU with virtual memory.

Do note that with modern compilers it's surprisingly hard to accidentally do something that is always guaranteed to write to 0. Because it is UB, and an optimizing compiler is allowed assume that it doesn't happen. This can lead to seemingly crazy things like a variable that is set to zero, and when you deref through it it gives you something completely different instead. Because if a variable is first set to zero in all code paths, and then complex logic usually sets it to something else, after which it is dereferenced, the compiler is allowed to notice that the path where it is accessed without being first set to something else never happens, and then it is allowed to notice that the first write to the variable is dead because it's never read before being set to something else, and thus can be eliminated.

Are there any languages other than C and C++ that have this “nasal demons” interpretation of undefined behavior?

I assume this is a product of sufficiently advanced compilers. Other LLVM languages almost certainly suffer from this too, including Zig, Swift and unsafe rust.

Are you asking if there are programming languages in which how undefined behaviour behaves is strictly defined?

I’m talking about the “non-local” flavor of undefined behavior. For example, I’d expect the following code:

  int x;
  printf("%d", x - x);

to always print 0, but it can it fact do anything at all.

I think so, at least when it comes to assuming that multi-threading data races don't happen.

Rust and Zig do, and I think also Go.

Not all memory bugs result in writing to a null pointer.

For example, you can do a double free, or write to a pointer that was freed.

I guess parent argues that:

  - humans have a track-record of writing memory bugs

  - memory-safe languages prevent such by construction

Therefore, what's the justification of not using a memory-safe language (as opposed to an unsafe one)?

> what's the justification of not using a memory-safe language

Use Go, Java or Fil-C, and memory safety is achieved at the expense of runtime performance. Tracing garbage collectors make your programs run slower and use more RAM.

With Rust you pay with complexity. Rust has new, weird syntax (lifetimes, HRTB, etc) and invisible borrow checker state that you've gotta understand and keep track of while programming. Rust is a painful language to learn, because lots of seemingly valid programs won't pass the borrow checker. And it takes awhile to internalise those rules.

I personally think the headache of rust is worth it. But I can totally understand why people come to the opposite conclusion.

> because lots of seemingly valid programs won't pass the borrow checker

Some straight-up valid programs as well

Rusts memory safety constructs do also impose a (much smaller) runtime performance penalty. Every Arc / Rc is a memory safe abstraction with runtime cost since rust has no way to prove cyclic reference graphs are safe at compile time.

Interop.

Arguably, calling it a key while insisting it's a non-sensitive ID was a mistake to start with

Changing the semantics of existing non-key keys, making them actually keys is horrendous

> Because walking away from it all isn't the right answer. Why? Because we leave behind all those people addicted to it.

Don't start drinking or smoking, because with this logic you'll have a really hard time quitting

Hydrogen ions are edible, although usually dissolved in water. Hydrogen ions existed before oxygen or water

Yep, I ensure I ingest a healthy amount of plain old-fashioned protons. Surely among nature's most ancient foods.

I don't like them, they taste sour: https://youtu.be/FSYE1T5d9jc?si=jQP90-q7QAHnrcJt

It's a staple food in some cultures. It needs preprocessing, but people have been doing that for a while

You can build a mergetool (https://git-scm.com/docs/git-mergetool)

One fundamental deal-breaking problem with structure aware version control is that your vcs now needs to know all the versions of all the languages you're writing in. It gets non-trivial fast.

It does! So extensible parser definition is another key piece of the technological puzzle along with common formats for parse trees.

Markdown is readable as plain text, that's kind of the point of it

There's also a pretty large jump between "I can ask the system to open this link in the default browser" and "I have built my own link handling in a memory-unsafe language to support some really fringe features, and oops it's exploitable"

Except memory-unsafe and fringe features have nothing to do with this CVE, which seems incredibly dumb on the face of it.

Replace Notepad with Chrome or Edge - clicking on a link downloads content from the Internet! Oh noes!

I haven't had time to look at it in detail but surely the vulnerability is more than a "click a URL".

No, that's exactly what the vulnerability is as far as I know.

"An attacker could trick a user into clicking a malicious link inside a Markdown file opened in Notepad, causing the application to launch unverified protocols that load and execute remote files." https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

Imagine some Markdown:

    [link](https://badsite.com)
    [link](file://C:/windows/system32/cmd.exe)
    [link](file://\\1.2.3.4\share\foo.exe)
    [link](ms-appinstaller://?source=https://badsite.com/bad.appx)

Wordpad, Notepad++ and many others highlight and let you double-click the URL in the first three lines, and yes they use the shell to open cmd.exe, yes they open remote shares (which if they're properly remote, the shell throws up a warning prompt asking if you want to connect). Wordpad always prompts if you want to open the link (and shows the link) before doing it, but you can click "Yes".

What's beyond the pale is that MS's new Notepad highlighted custom URIs like the fourth link, and let you click to open it without a prompt. Even web browsers will prompt at least once with a special modal dialogue, the first time you click on a link to a custom URI. For safety, a text editor should stick to highlighting http/https/file URIs only.

That's the "RCE", in the same way that telling a Linux user to type "curl | sudo bash" in their shell is "RCE".

The fix is that clicking the link now gives a dialogue box asking if you really want to click it, and remember to click no if you're not sure.

I wish they made this clearer as being the issue. It's what it came across to me like, but I couldn't actually say for sure that's what they meant because the CVE pages didn't make it obvious. And the comments here didn't help because everyone is just complaining about feature creep rather than discussing the actual problem.

Anyway, what this now has me thinking is, should protecting against this be expected to be done per-app or should it be at the OS level? It seems like it would make more sense to have the OS keep records on what application is allowed to open what kinds of links. Maybe with some mechanism to allow the app to cooperate with the OS if they want finer-grained permissions (such as a chat app passing the poster's user ID to the OS when invoking the link, so you could set an 'always allow' rule for links from specific users rather than the full app).