[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] stop run-time option processing after "--"

From: Matt Welland
Subject: Re: [PATCH] stop run-time option processing after "--"
Date: Mon, 13 Mar 2023 16:31:00 -0400
User-agent: Android

I really like these, I'll miss the -:b . My desired solution would be a way to turn off some or all switches. For some programs I'd disable for production, e.g. setuid, static compiled security related utils, we do a lot of these and I've wondered about security implications of these switches.

Get BlueMail for Android
On Mar 13, 2023, at 11:13 AM, Peter Bex <> wrote:
On Mon, Mar 13, 2023 at 10:37:30AM +0100, wrote:
Another problem with run-time option processing pointed out by
florz. This allows passing arguments that look like run-time
options, when preceded by "--".

This needs more thought - simply adding "--" to stop it from processing
options leaves us with ("--") as the first command-line argument.
In other words, "./my-program -:a100 -- foo" is seen as '("--" "foo")
when you ask for (command-line-arguments), while the intention probably
was '("foo").

Just dropping "--" from the arguments list is probably also not
desirable, because our option parser doesn't have any getopt-like
behaviour, so -xyz or --xyz aren't treated specially in any way.

Perhaps the safest here is to stop processing after reading ":-"
or some such (and discard it!) - that would be guaranteed to never
pass through to the program anyway, because it might be a runtime
option and already gets intercepted by the option parser.

Only potential issue is that it's not exactly standard when compared to
other programs...

What do y'all think?


reply via email to

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