GNU bug report logs - #30683
[PATCH] build: add a configure flag to force --sandbox

Previous Next

Full log

Message #27 received at 30683 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Jim Meyering <jim <at> meyering.net>
Cc: 30683 <at> debbugs.gnu.org, Assaf Gordon <assafgordon <at> gmail.com>,
 Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#30683: [PATCH] build: add a configure flag to force --sandbox
Date: Sun, 4 Mar 2018 01:19:20 -0500

[Message part 1 (text/plain, inline)]

On 02 Mar 2018 17:34, Jim Meyering wrote:
> On Fri, Mar 2, 2018 at 3:44 PM, Assaf Gordon <assafgordon <at> gmail.com> 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 <vapier <at> gentoo.org> 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 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.