5 ms·

Large parts of the foundation of Unix are absolutely, obviously outdated, starting from filesystems. There is nothing better yet for big chunks of Unix, but sys

Large parts of the foundation of Unix are absolutely, obviously outdated, starting from filesystems. There is nothing better yet for big chunks of Unix, but systemd (despite all its flaws) is a notable exception.

all2 5y ago
Can you expand on "starting from filesystems"?
- howinteresting 5y ago
  The fact that filesystems casually allow TOCTTOU races—and that those races cause security vulnerabilities unless you delve into arcane, OS-specific syscalls like renameat2—is an embarrassment.
  - all2 5y ago
    Username checks out. :D If I understand correctly, the issue is mutex on file objects at the kernel level. Basically it is a failing of the implementation of the "file" abstraction. Or perhaps a failing of the "file" abstraction itself? Per Wikipedia [0] (because I had no idea what a TOCTTOU race condition was) In the context of file system TOCTOU race conditions, the fundamental challenge is ensuring that the file system cannot be changed between two system calls. In 2004, an impossibility result was published, showing that there was no portable, deterministic technique for avoiding TOCTOU race conditions.[9] Since this impossibility result, libraries for tracking file descriptors and ensuring correctness have been proposed by researchers. It seems to me that solutions to the problem from inside the "files as an abstraction" space won't solve the problem. I was curious to see how a different abstraction would avoid this problem. Plan 9 FS appears to have had this issue at one point [1], but notably not because of the FS implementation itself. Rather the problem was caused by the underlying system's executing outside of the P9FS ordered access to a given file (someone please tell me if my understanding is incorrect). Here's an article that talks about the problems of this (and other) race conditions from the level of abstraction [2]. NOTE: I'm not claiming that P9FS is immune from this sort of attack, I'm only commenting on what I've found. [0] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use [1] https://bugs.launchpad.net/qemu/+bug/1911666 https://bugs.launchpad.net/qemu/+bug/1911666 [2] https://gavinhoward.com/2020/02/computing-is-broken-and-how-to-fix-it/ https://gavinhoward.com/2020/02/computing-is-broken-and-how-...
    - howinteresting 5y ago
      Exactly! I think the right way to deal with this is some sort of optimistic transaction support, such as SQLite's BEGIN CONCURRENT or git push --force-with-lease.

all2 5y ago

Can you expand on "starting from filesystems"?

howinteresting 5y ago
The fact that filesystems casually allow TOCTTOU races—and that those races cause security vulnerabilities unless you delve into arcane, OS-specific syscalls like renameat2—is an embarrassment.
- all2 5y ago
  Username checks out. :D If I understand correctly, the issue is mutex on file objects at the kernel level. Basically it is a failing of the implementation of the "file" abstraction. Or perhaps a failing of the "file" abstraction itself? Per Wikipedia [0] (because I had no idea what a TOCTTOU race condition was) In the context of file system TOCTOU race conditions, the fundamental challenge is ensuring that the file system cannot be changed between two system calls. In 2004, an impossibility result was published, showing that there was no portable, deterministic technique for avoiding TOCTOU race conditions.[9] Since this impossibility result, libraries for tracking file descriptors and ensuring correctness have been proposed by researchers. It seems to me that solutions to the problem from inside the "files as an abstraction" space won't solve the problem. I was curious to see how a different abstraction would avoid this problem. Plan 9 FS appears to have had this issue at one point [1], but notably not because of the FS implementation itself. Rather the problem was caused by the underlying system's executing outside of the P9FS ordered access to a given file (someone please tell me if my understanding is incorrect). Here's an article that talks about the problems of this (and other) race conditions from the level of abstraction [2]. NOTE: I'm not claiming that P9FS is immune from this sort of attack, I'm only commenting on what I've found. [0] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use [1] https://bugs.launchpad.net/qemu/+bug/1911666 https://bugs.launchpad.net/qemu/+bug/1911666 [2] https://gavinhoward.com/2020/02/computing-is-broken-and-how-to-fix-it/ https://gavinhoward.com/2020/02/computing-is-broken-and-how-...
  - howinteresting 5y ago
    Exactly! I think the right way to deal with this is some sort of optimistic transaction support, such as SQLite's BEGIN CONCURRENT or git push --force-with-lease.