clone: when symbolic links collide with directories, keep the latter

When recursively cloning a repository with submodules, we must ensure
that the submodules paths do not suddenly contain symbolic links that
would let Git write into unintended locations. We just plugged that
vulnerability, but let's add some more defense-in-depth.

Since we can only keep one item on disk if multiple index entries' paths
collide, we may just as well avoid keeping a symbolic link (because that
would allow attack vectors where Git follows those links by mistake).

Technically, we handle more situations than cloning submodules into
paths that were (partially) replaced by symbolic links. This provides
defense-in-depth in case someone finds a case-folding confusion
vulnerability in the future that does not even involve submodules.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit is contained in:
Johannes Schindelin
2024-03-28 10:55:07 +01:00
parent 850c3a220e
commit 31572dc420
3 changed files with 31 additions and 2 deletions

14
entry.c
View File

@ -541,6 +541,20 @@ int checkout_entry_ca(struct cache_entry *ce, struct conv_attrs *ca,
/* If it is a gitlink, leave it alone! */
if (S_ISGITLINK(ce->ce_mode))
return 0;
/*
* We must avoid replacing submodules' leading
* directories with symbolic links, lest recursive
* clones can write into arbitrary locations.
*
* Technically, this logic is not limited
* to recursive clones, or for that matter to
* submodules' paths colliding with symbolic links'
* paths. Yet it strikes a balance in favor of
* simplicity, and if paths are colliding, we might
* just as well keep the directories during a clone.
*/
if (state->clone && S_ISLNK(ce->ce_mode))
return 0;
remove_subtree(&path);
} else if (unlink(path.buf))
return error_errno("unable to unlink old '%s'", path.buf);