mirror of
https://github.com/privatevoid-net/nix-super.git
synced 2024-11-22 14:06:16 +02:00
No description
c05e20daa1
Suppose I have a path /nix/store/[hash]-[name]/a/a/a/a/a/[...]/a, long enough that everything after "/nix/store/" is longer than 4096 (MAX_PATH) bytes. Nix will happily allow such a path to be inserted into the store, because it doesn't look at all the nested structure. It just cares about the /nix/store/[hash]-[name] part. But, when the path is deleted, we encounter a problem. Nix will move the path to /nix/store/trash, but then when it's trying to recursively delete the trash directory, it will at some point try to unlink /nix/store/trash/[hash]-[name]/a/a/a/a/a/[...]/a. This will fail, because the path is too long. After this has failed, any store deletion operation will never work again, because Nix needs to delete the trash directory before recreating it to move new things to it. (I assume this is because otherwise a path being deleted could already exist in the trash, and then moving it would fail.) This means that if I can trick somebody into just fetching a tarball containing a path of the right length, they won't be able to delete store paths or garbage collect ever again, until the offending path is manually removed from /nix/store/trash. (And even fixing this manually is quite difficult if you don't understand the issue, because the absolute path that Nix says it failed to remove is also too long for rm(1).) This patch fixes the issue by making Nix's recursive delete operation use unlinkat(2). This function takes a relative path and a directory file descriptor. We ensure that the relative path is always just the name of the directory entry, and therefore its length will never exceed 255 bytes. This means that it will never even come close to AX_PATH, and Nix will therefore be able to handle removing arbitrarily deep directory hierachies. Since the directory file descriptor is used for recursion after being used in readDirectory, I made a variant of readDirectory that takes an already open directory stream, to avoid the directory being opened multiple times. As we have seen from this issue, the less we have to interact with paths, the better, and so it's good to reuse file descriptors where possible. I left _deletePath as succeeding even if the parent directory doesn't exist, even though that feels wrong to me, because without that early return, the linux-sandbox test failed. Reported-by: Alyssa Ross <hi@alyssa.is> Thanks-to: Puck Meerburg <puck@puckipedia.com> Tested-by: Puck Meerburg <puck@puckipedia.com> Reviewed-by: Puck Meerburg <puck@puckipedia.com> |
||
|---|---|---|
| .github | ||
| config | ||
| contrib | ||
| corepkgs | ||
| doc/manual | ||
| m4 | ||
| maintainers | ||
| misc | ||
| mk | ||
| nix-rust | ||
| perl | ||
| scripts | ||
| src | ||
| tests | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitignore | ||
| .version | ||
| bootstrap.sh | ||
| configure.ac | ||
| COPYING | ||
| local.mk | ||
| Makefile | ||
| Makefile.config.in | ||
| precompiled-headers.h | ||
| README.md | ||
| release-common.nix | ||
| release.nix | ||
| shell.nix | ||
Nix, the purely functional package manager
Nix is a new take on package management that is fairly unique. Because of its purity aspects, a lot of issues found in traditional package managers don't appear with Nix.
To find out more about the tool, usage and installation instructions, please read the manual, which is available on the Nix website at https://nixos.org/nix/manual.
Contributing
Take a look at the Hacking Section of the manual. It helps you to get started with building Nix from source.
License
Nix is released under the LGPL v2.1