re: kern/56673: don't allow execve with NULL argv

[matthew green <mrg%eterna.com.au@localhost>]

Jan Schaumann writes:
> If we already reject argv == NULL itself, as noted by
> mrg@, then I really don't see a good argument to allow
>
>     char *argv[1] = { 0 };
>
> POSIX does not appear to prohibit enforcing argv[0] to
> be non-NULL, and while it may at the same time _allow_
> argv[0] == NULL, it strikes me as entirely reasonable
> to prevent what almost inevitably is problematic.
>
> While we can fix all code in the NetBSD source tree to
> not assume argv[0] != NULL, we cannot do the same for
> all add-on software.  Preventing errant use of
> (albeit permissible) coding errors makes for a more
> robust OS.

while kre is technically correct that the "should" and
"shall" usage in the standard enables the current method,
the RATIONALE is pretty clear on what they prefer and
explicitly call out the accessing argv[0] issue.

   The wording, in particular the use of the word should,
   requires a Strictly Conforming POSIX Application to
   pass at least one argument to the exec function, thus
   guaranteeing that argc be one or greater when invoked
   by such an application. In fact, this is good practice,
   since many existing applications reference argv[0]
   without first checking the value of argc.

i'm failing to see any real benefit for this *except* if
you have an existing binary that relies upon this, though
i'd really like to understand this if it were true (and
why, if only to understand what went wrong...)

i think it's folly to try to fix every argv[0] usage in
the world.  there's probably new code written every day
that assumes argv[0] is valid.

i'm open to a sysctl to enable the existing usage for
anyone that absolutely needs it.


.mrg.