Skip to content

Fix long paths permanently breaking GC#3541

Merged
edolstra merged 1 commit intoNixOS:masterfrom
alyssais:gcdos
Apr 28, 2020
Merged

Fix long paths permanently breaking GC#3541
edolstra merged 1 commit intoNixOS:masterfrom
alyssais:gcdos

Conversation

@alyssais
Copy link
Copy Markdown
Member

@alyssais alyssais commented Apr 27, 2020

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/[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 directory file descriptors are being used outside of just
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.


Thanks to @puckipedia.

Checked on IRC whether I should report here or not given security implications.
Tarball THAT WILL BREAK YOUR GARBAGE COLLECTION

@alyssais
Copy link
Copy Markdown
Member Author

Looking into CI failures

@edolstra
Copy link
Copy Markdown
Member

Looks good to me, thanks!

There are probably a bunch of other places where we should use the *at() APIs to avoid hitting the path size limit, e.g. in NAR (de)serialization.

@alyssais
Copy link
Copy Markdown
Member Author

installcheck passes locally for me now

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>
@edolstra edolstra merged commit ee754f0 into NixOS:master Apr 28, 2020
@alyssais alyssais deleted the gcdos branch April 22, 2021 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants