From: Karl Chen <quarl@cs.berkeley.edu>
Date: Wed, 27 Aug 2008 03:05:35 GMT
Subject: Re: [PATCH] be paranoid about closed stdin/stdout/stderr
Message-ID: <quack.20080826T2005.lthzlmz2m4g@roar.cs.berkeley.edu>
In-Reply-To: <7v3akr2xa3.fsf@gitster.siamese.dyndns.org>

>>>>> On 2008-08-26 16:04 PDT, Junio C Hamano writes:

    Junio> I think

    Junio> 	$ git fetch 0<&-

    Junio> from the command line is a mere user stupidity.

    Junio> On the other hand, if a cron/at job that contains "git
    Junio> fetch" is launched in an environment with fd#0 (or #1
    Junio> or #2 for that matter) closed, it would certainly be
    Junio> problematic.  It can easily be worked around by
    Junio> redirecting file descriptors appropriately in the
    Junio> script that is launched, though.

I agree command-line 'git fetch 0<&-' is silly.  The example I
gave was minimized to show the symptom.  I ran across this with a
more complicated cron-ish setup that closes stdin.  I actually had
to look up the shell syntax for closing file descriptors.

Yes, I can work around this issue with sh -c 'git fetch
0</dev/null', and maybe it shouldn't close(0) in the first place.
But I don't see the harm in being safe.  It's one less potential
surprise for users.  This is the first program I've encountered
that broke due to stdin being closed, and it took debugging to
figure out that was the reason.

Re security, it's actually a good idea to be safe early on if it
could ever become an issue.  I keep /etc on my systems in version
control, and I've worked in production environments where some
users have access only via version control commands.