Page MenuHomeFreeBSD

libc/resolv: Refactor the option parser
AcceptedPublic

Authored by des on Sun, Jun 28, 8:13 AM.
Tags
None
Referenced Files
F161683703: D57923.id180852.diff
Sun, Jul 5, 10:34 PM
F161683467: D57923.id180852.diff
Sun, Jul 5, 10:31 PM
F161683281: D57923.id180852.diff
Sun, Jul 5, 10:28 PM
F161673702: D57923.id.diff
Sun, Jul 5, 8:25 PM
F161673388: D57923.diff
Sun, Jul 5, 8:21 PM
F161656345: D57923.id180943.diff
Sun, Jul 5, 4:12 PM
F161656067: D57923.id180943.diff
Sun, Jul 5, 4:08 PM
Unknown Object (File)
Sun, Jul 5, 12:50 AM
Subscribers

Details

Reviewers
kevans
markj
Summary

Start the loop by finding the end of the option name, the name-value
separator (if any), and the end of the option. Use those pointers to
simplify matching the option name and parsing the option value, and
validate option names and values more strictly. This means that:

  • We no longer accept trailing garbage in an option name or value. For instance, we would previously interpret “edns0123” as “edns0” and “timeout:3xyz” as “timeout:3”. This was actually quite lucky because we also failed to recognize the newline at the end of the option line as a whitespace character.
  • For options that take a numerical argument, we would previously accept negative values and treat non-numerical arguments as 0, while large numerical arguments would be capped to the option's maximum permitted value. Now, any failure to parse the argument, including overflow, results in the option being left unchanged.

MFC after: 1 week

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 74350
Build 71233: arc lint + arc unit

Event Timeline

lib/libc/resolv/res_init.c
555

Do we want to reset errno and explicitly complain about ERANGE here (and below)? It'll get smashed back down to RES_MAXNDOTS anyways, but maybe worth pointing out as a larger problem?

lib/libc/resolv/res_init.c
555

We have no way of communicating the problem. The best we can do is constrain the value to the expected range. We are however missing a num >= 0 here...

add missing lower bound check on ndots

leave options unchanged on misparse

For options that take a numerical value, we would previously happily set a numerical option to a negative value and treat non-numerical arguments as 0, while a numerical argument that happened to exceed the maximum for the option would result in the option being set to its default value. Now, any failure to parse the argument, including overflow, results in the option being set to its default value.

This is worth an entry in RELNOTES IMO.

lib/libc/resolv/res_init.c
605

This option isn't documented any AFAICS. From the implementation I wonder if it should be debug-only in some sense.

This revision is now accepted and ready to land.Tue, Jun 30, 2:03 PM
lib/libc/resolv/res_init.c
605

yeah idek what it does...