Re: [Bug 212887] Clarify getopt.3 behaviour

Re: [Bug 212887] Clarify getopt.3 behaviour

[Alejandro Colomar (man-pages)]

Hi James,

On 5/2/21 5:16 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=212887
> 
> --- Comment #8 from James Hunt (jamesodhunt@gmail.com) ---
> Hi Alex,
> 
> Thanks for reviewing again. I've updated the patch to v3 which now only
> includes the first two changes.

Okay, I'll have a look at it.

> 
> I agree - I was in two minds about the WARNINGS section myself...
> 
> # Validating input
> 
> Good programmers should know to do this. But given that `getopt` is a primary
> interface to a program (which might be running `SUID-root` for example), I
> wonder if it needs to be "called out" more strongly? There are lots of other
> syscalls and library calls that might deserve similar treatment of course. In
> fact, I wonder a new "security` man page might be an interesting project, since
> that could summarise expectations, security + safety advice to programmers, and
> refer to man pages like `getopt(3)`. that would also avoid cluttering the main
> man pages as the details could be provided in the security one.

I like that idea.  Could you draft such a page?  I know it's asking a
very hard work, but maybe start with some basic ideas.

Also, security is a very broad thing.  Maybe small pages restricted to a
specific context are easier to handle.  For example, one page dedicated
to security in the context of user input in programs, which could treat
things like getopt(3), scanf(3), fgets(3), and their families of
functions (and maybe some others)

If you would like to do this, could you please start a new thread by
writing a new email, and CC the mailing list <linux-man@vger.kernel.org>
(and any other lists that may be interested, such as probably
<libc-alpha@sourceware.org>, please?.

> 
> # Numeric options
> 
> Yes, the user is responsible for a well formed command line. However, I was
> trying to raise the fact that the programmer needs to be even more careful in
> the case of the program using getopt to support numeric options which doesn't
> seem to be that common, but could lead to unexpected trouble if a programmer
> decides to use that feature of getopt.
> 

getopt(3) just gets strings (it does something more, but let's
simplify).  In that sense it's very similar to fgets(3) as an interface
(even safer, as it doesn't write to a buffer).  It's strtol(3) or
whatever function that will convert the input into a number the one that
has to take care of the input limits.

Also,

As long as the user uses the options correctly, numeric options are just
another character.  They're treated exactly in the same way.  And in the
case of long options, everything is a string, even if it has numbers in it.

The only valid case where a number is treated as a number is in an
option argument (in the case that the option has a numeric argument).
But in this case, it is still a string at the time of getopt(3).  And in
this case, the programmer already expects a number, so I don't think any
warning applies.

It is only when the user inputs options in the wrong order that numbers
and options may be mixed and unexpected things may happen, but invalid
input resulting in undefined behavior is not an issue.



Thanks,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/