On Fri, Nov 25, 2011 at 09:43:14AM +0530, Sitaram Chamarty wrote:
> The quick summary, in the words of Jeff (second post in that link) is:
> "Because [upload]-pack runs as the user who is [fetching], not as the
> repository owner. So by convincing you to [fetch from] my repository
> in a multi-user environment, I convince you to run some arbitrary code
> of mine."
>
> My contention (today) is:
>
> - you're already taking that risk for push
> - so this would add a new risk only for people who fetch but don't push
> - which, I submit, is a very small (if not almost empty) set of people
>
> I may be wrong but I imagine shared environments are those where
> almost everyone will push at least once in a while. It's a closed
> group of people, probably all developers, etc etc etc...
One thing to note is that this is _only_ an issue on systems where the
user running upload-pack (or receive-pack, for push) is not the same as
the user who owns the hooks directory. So basically two situations:
1. Alice and Bob are developers on a multi-user system with ssh
access. Alice will run "git fetch ~bob/project.git" or "git fetch
alice@server:~bob/project.git". She executes Bob's hooks as
herself on the server.
2. Somebody runs a git:// server, locked down under a "git" user (or a
smart-http server, under a "www" account). If users of the service
can write their own hooks, they will run as the "git" user.
But there are many situations that don't fall under this umbrella. In
(1), maybe Alice and Bob decide that they trust each other enough, and
the hook is more important than the security issue. In (2), users of the
service might not be able to write their own hooks (this is the case for
GitHub, and I assume also for Gerrit).
There should be a way for people who aren't in one of those dangerous
situations to be able to use a hook. The important thing is to set the
defaults in such a way that the people who _are_ in that situation
aren't left in a vulnerable situation.
The easiest way would be something like a "trust remote hooks"
environment variable, off by default. Admins in situation (2) could set
it for their git-daemon (or webserver, or whatever, or
gitolite-over-ssh), once they decided it was safe.
It could also help with (1), but I think you would need to take special
steps to propagate the variable in the "git fetch server:project.git"
case.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html