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

[Jim Meyering]

On Sat, Mar 3, 2018 at 10:19 PM, Mike Frysinger <address@hidden> wrote:
> 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

Maybe it would help to explain what your intended use case is. I.e.,
why do you want this?

Do you want to do something similar for perl, awk, python, etc?

>> 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.

Sure, there would be overhead for the interpreter and interposed
"exec". Other than that, what is not satisfactory?

> what about a configure option to disable these commands entirely at compile
> time ?

That runs afoul of the same guideline: it changes the language that sed accepts.

> 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 ?

Currently, any GNU sed binary can be expected to provide certain
fundamental features.
If we provide the suggested configure option, that implies that robust
scripts may want to (or have to) detect the new variant and do
something differently when it is found. But this is just the first
such option. If we make it easy to add a second such configure-time
option, there would then be four possible variants. Clearly that would
not scale.