Hacker News Reader

Comment by blueflow | Hacker News Reader

The uutils project has the right goals - 1:1 compatibility with GNU coreutils to the extent that any difference in functionality is a bug.

The first comment on LWN is about a bug in the more(1) from uutils. I checked out that code, found some oddities (like doing stat() on a path to check if it exists, right before open()ing it) and went to check against how GNU coreutils does it.

Turns out coreutils does not do it at all, because more(1) is from util-linux. ta-dam.

View on HN

I think this is an excellent point that a lot of people are missing.

There are a lot of GNU utils. For now, Ubuntu is only taking on the ones that are actually in coreutils. Those are the ones that uutils considers "production ready".

> > Klode said that it was a bad idea to allow users to select between Rust and non-Rust implementations on a per-command level, as it would make the resulting systems hard to support.

Wouldn't this imply that these aren't actually 1:1 replacements?

It would imply not all of the replacements are complete and/or bug free yet, and the article gives examples of just that earlier in the text, but it would not imply the replacements lack the goal of being 1:1 replacements like GP said.

This would seem to be one of the driving factors in the creation of oxidizr: to allow testing how ready the components are to be drop in replacements with easy recourse. You can read more about that in this section of the linked blog post by jnsgruk https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...

  uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.

-- https://github.com/uutils/coreutils?tab=readme-ov-file#goals

>The uutils project has the right goals

Their goals are to _replace GPL's code_. It's a subtle attack on Free Software by providing corporations a workaround so they don't have to abide by the terms of the license.

Nobody seriously doubts the efficiency or safety of the GNU Coreutils. They've been battle tested for over 30 years and whatever safety or optimization risks are left are negligible.

That's funny because just today I was reading the Rust docs for std::fs::File and saw a warning about that exact TOCTOU error, and had to fix my code to not hit it

std::fs is generally not a good API with the complete lack of directory handles.

the more you know

Not sure why you are downvoted but I’m curious why. I appreciated this tidbit, thanks.

And? How does that do it?

I checked. It fopen's the file and then fstat's it. So it isn't vulnerable to TOCTOU.

However the TOCTOU is completely benign here. It's just an extra check before Rust opens the file so if you were to try to "exploit" it the only thing that would happen is you get a different error message.

> if you were to try to "exploit" it the only thing that would happen is you get a different error message

Can't reproduce this. If I do

    sudo strace -e inject=stat:delay_exit=30s:when=2 ./coreutils more foo

on one terminal and

    rm foo
    ln -s /etc/passwd foo

on another, I can see the contents of /etc/passwd on the first one.

Uhm yeah well now try

  ln -s /etc/passwd foo
  sudo more foo

OMG! The original version is "vulnerable" too!

(I did not know about that strace feature though - that is very cool, thanks!)

I thought I was gonna see an error because the stat'd file and the opened one didn't match. How disappointing

No, it just means you're checking the wrong file so you might not get the nice error message from the initial check.

It's still not going to do anything incorrect when it comes to actually open the file though.

TOCTOU only matters when the check is actually checking something important. Here it isn't; it's just giving nicer error messages. If you bypass it you just lose those nice error messages.

So it isn't a problem here.

Reply on news.ycombinator.com