16 ms·

This isn't specific to bash scripts, this can happen to pretty much any file. What we really need is a way for a process to atomically "check out" a copy of a f

• usefulcat 6y ago
  While technically true, there's an enormous difference between a window of vulnerability that lasts some fraction of a second (the time needed to read the entire file from the filesystem) and multiple seconds, hours, days or even months depending on how long the script runs.
• wahern 6y ago
  An atomic read fork isn't sufficient. The file could be inconsistent if another process is currently writing to the file at the moment of the snapshot. What you need is an atomic write, which is already provided by rename(2). I've always found it odd that binaries and scripts are often installed 755, including in /bin and /sbin.[1] Perhaps it's because install scripts don't bother changing the read-write permissions, so executable end up with 755 because the default umask is 022. Anyhow, I've taken to removing all write permissions from most of my files, not just executables. I haven't yet experimented with changing my umask to 222, but I suspect it would cause many programs, especially editors, to fail. [1] At least on Linux. I just checked OpenBSD and they're 555. But even on OpenBSD most files in /usr/local/{bin,sbin}, installed by third-party packages, are 755.
• wtetzner 6y ago
  MVCC for filesystems?