The trouble with symbolic links

There doesn't seem to be a way to batch together operations that involve walking through directories and symlinks to do something to a file. This seems to be a major source of complexity.

IMO the article's conclusion is backwards. There's nothing wrong with symlinks when files are opened with openat(), since in principal the program (or controlling program) should always be in control of the filesystem layout. It's open() that causes problems, and complex interactions with symlinks in attacker-controlled directories are just one of them.

The POSIX file API was designed before the concept of capability passing (arguably, before the concept of computer security in general). A modern replacement would look more like Fuchsia, where child processes are provided file access scoped to their parent process's authority. This same scoping can also be used within a process, for example to implement a server that can "self-chroot".

  > So, more functions following the pattern of openat() had to be created
  > [...]
  > Some are still missing, like getxattrat() and setxattrat().

The functions to get/set xattrs on a file descriptor (rather than a path) are fgetxattr() and fsetxattr(). They're not usable for the specific case of a file descriptor opened with O_PATH, but that restriction is both documented and reasonable -- O_PATH doesn't allow operations that inspect the state of the file itself, such as reading/writing.

A better example might have been listxattr() vs flistxattr(), because the former works on a file without read permissions, but the latter fails on a descriptor opened with O_PATH.

  listxattr("xattr-chmod000.txt", NULL, 0)         = 14
  listxattr("xattr-chmod000.txt", "user.testattr\0", 14) = 14
  getxattr("xattr-chmod000.txt", "user.testattr", NULL, 0) = -1 EACCES (Permission denied)

vs

  openat(AT_FDCWD, "xattr-chmod000.txt", O_RDONLY|O_PATH) = 3
  flistxattr(3, NULL, 0)                  = -1 EBADF (Bad file descriptor)

I always thought Unix v7+ should have added some kind way to do atomic groups of syscalls, eg:

  begin_transaction ();
  lstat ("/path", ...);
  lstat ("/path/foo", ...);
  commit ();

In Unix v7 mkdir was not a system call. It was a setuid program implemented using mknod + link. That was racy so the mkdir(2) system call was added. But it could have been solved more generally (and more elegantly) by adding transactions.

It could also solve the whole thing with ending up with zero-length files because you didn't use the right incantation to update a file atomically on ext4 (https://thunk.org/tytso/blog/2009/03/12/delayed-allocation-a...).

Symlinks work as intended, but they cause a lot of unintended security vulnerabilities, i.e. they break lots of otherwise-functioning code.

You can play with your words and redefine their meanings, but the vulnerabilities remain.

They have been around for 40+ years, they don't break code unless we are talking about code predating their introduction. It is not me playing with words, I am just pointing out a tired trope.