On Mon, Nov 28, 2011 at 01:47:44PM +0530, Sitaram Chamarty wrote: > > Jeff may be right that any approach based on hooks cannot be made totally > > safe. But the discussion can lead to a workable alternative. The "enable > > the hook only on git:// and http:// and no other" approach might or might > > not be such a workable alternative. The "try talking to a service process > > via named pipe, instead of spawning a hook" might or might not be such a > > workable alternative. Other possibilities may be there to be explored. > > There are only 2 cases: git-upload-pack runs as invoking user, or it > runs as some common user/repo owner. I think it is slightly more complicated. You may have a common user, but that user may or may not trust the contents of the repo on disk (e.g., a system daemon serving repos for arbitrary users). > I see pre-upload hooks for case 1 as being hard/impossible to do, > while case 2 is trivial (just check if the hook file owner == UID of > the git-upload-pack process). The UID check doesn't quite tell you what you want. If I am in a shared repo situation with a liberal umask and I write a hook, it will have my UID. But it may have group-write permissions. Other people in my group can write arbitrary contents to the file, but it will retain my UID, and git's check will think the code is OK to run. > Yes, this means pre-upload won't work identically in *all* setups. > But as you said somewhere: perfect is the enemy of good. Yes, I think we have to accept inconsistency if we have them at all. Because such hooks are dangerous in some setups, and OK in others. So no matter what the rule for determining danger, they will sometimes run and sometimes not. -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