3 ms·

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

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.

cWave 2y ago
the more you know
samtheprogram 2y ago
Not sure why you are downvoted but I’m curious why. I appreciated this tidbit, thanks.
jgtrosh 2y ago
And? How does that do it?
- IshKebab 2y ago
  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.
  - oguz-ismail 2y ago
    > 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.
    - IshKebab 2y ago
      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!)
      - oguz-ismail 2y ago
        I thought I was gonna see an error because the stat'd file and the opened one didn't match. How disappointing
        IshKebab 2y ago
        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.
secondcoming 2y ago
> > 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?
- zamadatix 2y ago
  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-oxidising-ubuntu/56995#p-144776-introducing-oxidizr https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...
- blueflow 2y ago
  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 https://github.com/uutils/coreutils?tab=readme-ov-file#goals
LeFantome 2y ago
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".
01HNNWZ0MV43FF 2y ago
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
- Starlevel004 2y ago
  std::fs is generally not a good API with the complete lack of directory handles.
codeguro 2y ago
>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.

cWave 2y ago

the more you know

samtheprogram 2y ago

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

jgtrosh 2y ago

And? How does that do it?

IshKebab 2y ago
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.
- oguz-ismail 2y ago
  > 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.
  - IshKebab 2y ago
    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!)
    - oguz-ismail 2y ago
      I thought I was gonna see an error because the stat'd file and the opened one didn't match. How disappointing
      - IshKebab 2y ago
        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.

secondcoming 2y ago

> > 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?

zamadatix 2y ago
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-oxidising-ubuntu/56995#p-144776-introducing-oxidizr https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...
blueflow 2y ago
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 https://github.com/uutils/coreutils?tab=readme-ov-file#goals

LeFantome 2y ago

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".

01HNNWZ0MV43FF 2y ago

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

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

codeguro 2y ago

>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.