]> git.ipfire.org Git - thirdparty/git.git/commit - apply.c
verify_path: disallow symlinks in .gitmodules
authorJeff King <peff@peff.net>
Sat, 5 May 2018 00:03:35 +0000 (20:03 -0400)
committerJeff King <peff@peff.net>
Tue, 22 May 2018 03:50:11 +0000 (23:50 -0400)
commit10ecfa76491e4923988337b2e2243b05376b40de
tree47fd3ecfa1590f62eaa65dced6aef152a85b33e6
parenteb12dd0c764d2b71bebd5ffffb7379a3835253ae
verify_path: disallow symlinks in .gitmodules

There are a few reasons it's not a good idea to make
.gitmodules a symlink, including:

  1. It won't be portable to systems without symlinks.

  2. It may behave inconsistently, since Git may look at
     this file in the index or a tree without bothering to
     resolve any symbolic links. We don't do this _yet_, but
     the config infrastructure is there and it's planned for
     the future.

With some clever code, we could make (2) work. And some
people may not care about (1) if they only work on one
platform. But there are a few security reasons to simply
disallow it:

  a. A symlinked .gitmodules file may circumvent any fsck
     checks of the content.

  b. Git may read and write from the on-disk file without
     sanity checking the symlink target. So for example, if
     you link ".gitmodules" to "../oops" and run "git
     submodule add", we'll write to the file "oops" outside
     the repository.

Again, both of those are problems that _could_ be solved
with sufficient code, but given the complications in (1) and
(2), we're better off just outlawing it explicitly.

Note the slightly tricky call to verify_path() in
update-index's update_one(). There we may not have a mode if
we're not updating from the filesystem (e.g., we might just
be removing the file). Passing "0" as the mode there works
fine; since it's not a symlink, we'll just skip the extra
checks.

Signed-off-by: Jeff King <peff@peff.net>
apply.c
builtin/update-index.c
cache.h
read-cache.c