All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Eugene Sajine <euguess@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Fwd: Fwd: git-daemon access-hook race condition
Date: Thu, 12 Sep 2013 15:20:19 -0700	[thread overview]
Message-ID: <xmqqa9jhof6k.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqioy5oiif.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Thu, 12 Sep 2013 14:08:24 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> 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).

Scratch that "exit status" part, as I do not think it is useful.

To a receive-pack and a send-pack that is talking to it, if a push
results in a failure, it is a failure.  Likewise for upload-pack and
fetch-pack for a transfer in the reverse direction.

And the way that failure is communicated from the receive-pack to
the end-user via the send-pack is for the receive-pack to send a
protocol message that tells the send-pack about the failure, and the
send-pack showing the error message and signalling the failure with
its exit status.  Likewise for upload-pack and fetch-pack (hence
"fetch", which is conceptually a thin wrapper around it).

Between the deamon and the receive-pack (or the fetch-pack) process,
however, such a failed push (or fetch) is still a success.  "I
correctly diagnosed and successfully sent a rejection notice to the
other end" is signalled by receive-pack to the daemon by exiting
with success (i.e. 0) exit status.

So even if we feed the exit status of the service process to the
hook script specified by the --post-service-hook, it does not tell
the script if the service "succeeded" in that sense.

  parent reply	other threads:[~2013-09-12 22:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAPZPVFa=gqJ26iA6eQ1B6pcbTcQmmnXHYz6OQLtMORnAa5ec2w@mail.gmail.com>
2013-09-12 18:51 ` Fwd: git-daemon access-hook race condition Eugene Sajine
2013-09-12 19:15   ` Junio C Hamano
     [not found]     ` <CAPZPVFZLPV=JVR+SSqfX-=aLyFWZBkof+yCkivcLoKNnv6f__Q@mail.gmail.com>
2013-09-12 20:30       ` Fwd: " Eugene Sajine
2013-09-12 21:08         ` Junio C Hamano
2013-09-12 21:16           ` Eugene Sajine
2013-09-12 22:01             ` Eugene Sajine
2013-09-13 17:17               ` Eugene Sajine
2013-09-12 22:20           ` Junio C Hamano [this message]
2013-09-12 23:17             ` Eugene Sajine
2013-09-12 23:27               ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqa9jhof6k.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=euguess@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.