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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/56673; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Joerg Sonnenberger <joerg%bec.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, jschauma%netmeister.org@localhost
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Sun, 30 Jan 2022 23:54:47 +0700

     Date:        Sun, 30 Jan 2022 16:53:17 +0100
     From:        Joerg Sonnenberger <joerg%bec.de@localhost>
     Message-ID:  <Yfa0bYr9dWHjMajW%bec.de@localhost>
 
   | IMO POSIX at least implies that argc > 0:
   |
   |   The argument arg0 should point to a filename string that is associated
   |   with the process being started by one of the exec functions.
 
 No, that cannot be read that way.   That it says "should" and not "shall"
 in any case makes it clear it is a recommendation, not a requirement, but
 that one is also clearly aimed at application writers, indicating to them
 the convention for the use of argv.
 
 If that sentence meant what you're suggesting it might, then as well as
 making
 	argv[] = { NULL };
 invalid, we'd also need to make
 	argv[] = { "", NULL };
 invalid, as "" isn't a proper filename string for anything, let alone
 being associated with the process being started.
 
 Further, it might also prohibit the (ancient) tradition of indicating
 a login shell by making the first char of arg0 be '-', as "-sh" isn't
 a filename string associated with the process either (nor are -ksh -csh
 -tsch -bash ...)
 
 If POSIX really intended to prohibit having no args at all (as distinct
 from no arg vector at all) then it would be much more explicit than that,
 and the requirement would be on the implementation to enforce it, not on
 the application.   For that there'd be an errno value defined to indicate
 this "error", and there isn't.   mrg's proposed patch uses EINVAL (which
 is the one most likely to apply), but in the POSIX exec functions:
 
 [EINVAL]  The new process image file has appropriate privileges and has
           a recognized executable binary format, but the system does not
           support execution of a file with this format.
 
 That's it for EINVAL for exec*() - nothing relating to the arg lists at
 all.   [Aside: I know that implementations are permitted to use new errno
 values, or ones assigned for a purpose beyond that for which they are
 defined, provided that doing do doesn't usurp some other errno value that
 should have been returned instead ... that is, I am not claiming that
 the proposed patch is a POSIX violation.]
 
   | I really don't see a point in allow argc==0 to be valid.
 
 I don't see a use for it either.   But the number of things I don't
 see a use for, which turn out to be quite useful, is almost beyond
 comprehension.
 
 What I don't see is any good reason (beyond laziness in fixing broken
 applications) for making this change.
 
 kre