Re: Fwd: Fwd: git-daemon access-hook race condition

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 12, 2013, 21:08 UTC
Message-ID: <xmqqioy5oiif.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAPZPVFZpYJnQY4BpjaPxU8NnBmPZ9Fp6UpovoQEvkKzRnLa=KA@mail.gmail.com>

Eugene Sajine <euguess@gmail.com> writes:

> So are you really sure that it is a non-starter to have
> --before-service/--after-service options for access-hook?

Given the definition of "--access-hook" in "git help daemon":

    --access-hook=<path>::
            Every time a client connects, first run an external command
            specified by the <path> ... The external command can decide
            to decline the service by exiting with a non-zero status (or
            to allow it by exiting with a zero status)....

There is *NO* way in anywhere --after-service makes any sense (and by definition --before-service is redundant).

What you _could_ propose is to define a *new* hook that is run when the spawned service has returned, with the same information that is fed to the access hook (possibly with its exit status).

I do not offhand know if we retain the original service information that long after the main daemon process has spawned the service process, though. With the current system, the only thing it needs to know is the PID of the service processes that are to be culled by calls to waitpid(). So you may have to extend existing bookkeeping data structures a bit to keep those pieces of information around if you wanted to add such a new hook.