docs: document security issues around untrusted .git dirs
For a long time our general philosophy has been that it's unsafe to run arbitrary Git commands if you don't trust the hooks or config in .git, but that running upload-pack should be OK. E.g., see1456b043fc
(Remove post-upload-hook, 2009-12-10), or the design of uploadpack.packObjectsHook. But we never really documented this (and even the discussions that led to1456b043fc
were not on the public list!). Let's try to make our approach more clear, but also be realistic that even upload-pack carries some risk. Helped-by: Filip Hejsek <filip.hejsek@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit is contained in:

committed by
Johannes Schindelin

parent
7b70e9efb1
commit
e69ac42fcc
@ -71,6 +71,21 @@ This is implemented by having `upload-pack` internally set the
|
||||
you trust it), you can explicitly set `GIT_NO_LAZY_FETCH` to
|
||||
`0`.
|
||||
|
||||
SECURITY
|
||||
--------
|
||||
|
||||
Most Git commands should not be run in an untrusted `.git` directory
|
||||
(see the section `SECURITY` in linkgit:git[1]). `upload-pack` tries to
|
||||
avoid any dangerous configuration options or hooks from the repository
|
||||
it's serving, making it safe to clone an untrusted directory and run
|
||||
commands on the resulting clone.
|
||||
|
||||
For an extra level of safety, you may be able to run `upload-pack` as an
|
||||
alternate user. The details will be platform dependent, but on many
|
||||
systems you can run:
|
||||
|
||||
git clone --no-local --upload-pack='sudo -u nobody git-upload-pack' ...
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
linkgit:gitnamespaces[7]
|
||||
|
Reference in New Issue
Block a user