bug-sed
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]