Re: [PATCH 29/29] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells
- From
Jeff King <peff@peff.net>
- Date
- Jun 28, 2018, 14:35 UTC
- Message-ID
- <20180628143513.GB16657@sigill.intra.peff.net>
- In-Reply-To
- <CAPig+cRzZ-Nd2b-M8v0NUsLX_gkKwLqyakgcRhwGf3CzsWwxBA@mail.gmail.com>
On Tue, Jun 26, 2018 at 05:13:05PM -0400, Eric Sunshine wrote:
Show 29 quoted lines
> On Tue, Jun 26, 2018 at 5:01 PM Jeff King <peff@peff.net> wrote:
> > On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
> > > Some of these dangers can be de-thoothed during the linting phase by
> > > defining do-nothing shell functions:
> > >
> > > cp () { :; }
> > > mv () { :; }
> > > ln () { :; }
> > >
> > > That, at least, makes the scariest case ("rm") much less so.
> >
> > Now that's an interesting idea. We can't catch every dangerous action
> > (notably ">" would be hard to override), but it should be pretty cheap
> > to cover some obvious ones.
>
> Taking the idea a bit further, the 'sed' script could also throw away
> strings of "../" inside subshells, which would help defang the more
> difficult cases, like "echo x >../git.c". There are pathological
> cases, of course, which it wouldn't catch:
>
> P=../git.c
> test_expect_success 'foo' '
> (
> cd dir &&
> echo x >$P
> )
> '
>
> but it does help mitigate the issue for the most typical cases.It seems like the dangerous thing there is ">", not necessarily "..". Could we just s/>/x/g ?
That "breaks" the commands in a sense, but the whole point is that these commands shouldn't ever be run in the first place.
-Peff