On Thu, Jul 07, 2016 at 03:06:31PM -0700, Stefan Beller wrote: > > The problem is for hosting sites which serve repositories via git-daemon > > from untrusted users who have real shell accounts (e.g., you set up > > git-daemon to run as the "daemon" user serving repositories out of > > people's home directories; you don't want users to escalate their shell > > access into running arbitrary code as "daemon"). > > I think you would want to lock down the > hosting site as much as possible and not put untrusted users home > directories on there? So it is hard for me to imagine you'd go for such a setup > in practice. Sure, I think that's a good way to run a hosting site, too. But it doesn't mean people don't have other needs. kernel.org was run as I mentioned above for many years. Another related case: you have a multi-user server where Alice might run "git fetch server:~bob/repo.git". Alice does not want to run arbitrary code based on what is in Bob's repo.git. Even if they are in the same company, it is a poor security practice. > > But I don't think that case applies here. That is about running > > upload-pack on an untrusted repository, but your changes here are part > > of receive-pack. In such a scenario, users should be pushing as > > themselves via ssh. And if they are not (e.g., the admin set up > > push-over-smart-http centrally), they are already screwed, as a > > malicious user could just set up a pre-receive hook. > > I hear that as: "The pre-receive hook itself can do much more > damage than an oversized push option payload". Exactly. Or more to the point: we promise nothing here except for upload-pack, so changes to receive-pack do not have to worry about this issue at all. -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