[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30683: [PATCH] build: add a configure flag to force --sandbox
From: |
Mike Frysinger |
Subject: |
bug#30683: [PATCH] build: add a configure flag to force --sandbox |
Date: |
Sun, 4 Mar 2018 01:19:20 -0500 |
On 02 Mar 2018 17:34, Jim Meyering wrote:
> On Fri, Mar 2, 2018 at 3:44 PM, Assaf Gordon <address@hidden> wrote:
> > Hello Eric, Mike,
> >
> > (replying to both recent messages)
> >
> > On Fri, Mar 02, 2018 at 05:20:07PM -0600, Eric Blake wrote:
> >> On 03/02/2018 05:07 PM, Assaf Gordon wrote:
> >>
> >> >Adding such "--enable" options to "./configure" goes against the gnu
> >> >coding standards,
> >>
> >> Would a different spelling, such as '--with-forced-sandbox-default=on/off'
> >> be better?
> >
> > On Fri, Mar 2, 2018 at 4:27 PM, Mike Frysinger <address@hidden> wrote:
> >> [...] so if you tell me what name you
> >> want, i'll happily adjust the patch/code.
> >
> > I generally do not object to this feature (regardless of the name).
> >
> > However when I previously suggested something similar for coreutils [1]
> > (a ./configure flag to change the default 'ls' quoting style),
> > it was explained that such things should be avoided [2].
> >
> > [1] https://lists.gnu.org/archive/html/bug-coreutils/2016-02/msg00057.html
> > [2] https://lists.gnu.org/archive/html/bug-coreutils/2016-02/msg00058.html
> >
> > Perhaps there's no issue in adding it to sed - in which case I'm happy to
> > commit it.
> >
> > Jim - what do you think?
>
> I think you made the right call by declining this change. The trouble
> with any such configure-time option is that then any script that
> requires a legitimate use of those sed commands would fail.
those scripts should fail on these systems
> Mike, it sounds like you want an environment in which every sed use
> would resolve to a specially-built sed binary. Given that you can do
> that, can't you interpose a wrapper that invokes the real sed with
> --sandbox?
that would add useless (to me) overhead on the system and simultaneously
not [satisfactorily] resolve the issue. we want to kill all such escapes
on the system.
what about a configure option to disable these commands entirely at compile
time ?
i don't really understand the argument of "adding a wrapper `sed` that adds
--sandbox all the time is OK, but changing `sed` to always use --sandbox is
not OK". how is this any different to "legitimate" scripts ?
-mike
signature.asc
Description: Digital signature
bug#30683: [PATCH] build: add a configure flag to force --sandbox, Mike Frysinger, 2018/03/02