Skip to content

Remove panic in nat package on invalid hostport#14682

Merged
calavera merged 1 commit intomoby:masterfrom
duglin:Issue14621
Jul 21, 2015
Merged

Remove panic in nat package on invalid hostport#14682
calavera merged 1 commit intomoby:masterfrom
duglin:Issue14621

Conversation

@duglin
Copy link
Copy Markdown
Contributor

@duglin duglin commented Jul 16, 2015

Closes #14621

This one grew to be much more than I expected so here's the story... :-)

  • when a bad port string (e.g. xxx80) is passed into container.create()
    via the API it wasn't being checked until we tried to start the container.
  • While starting the container we trid to parse 'xxx80' in nat.Int()
    and would panic on the strconv.ParseUint(). We should (almost) never panic.
  • In trying to remove the panic I decided to make it so that we, instead,
    checked the string during the NewPort() constructor. This means that
    I had to change all casts from 'string' to 'Port' to use NewPort() instead.
    Which is a good thing anyway, people shouldn't assume they know the
    internal format of types like that, in general.
  • This meant I had to go and add error checks on all calls to NewPort().
    To avoid changing the testcases too much I create newPortNoError() JUST
    for the testcase uses where we know the port string is ok.
  • After all of that I then went back and added a check during container.create()
    to check the port string so we'll report the error as soon as we get the
    data.
  • If, somehow, the bad string does get into the metadata we will generate
    an error during container.start() but I can't test for that because
    the container.create() catches it now. But I did add a testcase for that.

Signed-off-by: Doug Davis [email protected]

@runcom
Copy link
Copy Markdown
Member

runcom commented Jul 17, 2015

LGTM

Comment thread pkg/nat/nat.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this, and is a bit dangerous to to add functions just to support a test case.
Tests can just do p, _ just as this function is, or add a test helper called newPort that does this.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of adding a test util func - will do that.

Closes moby#14621

This one grew to be much more than I expected so here's the story... :-)
- when a bad port string (e.g. xxx80) is passed into container.create()
  via the API it wasn't being checked until we tried to start the container.
- While starting the container we trid to parse 'xxx80' in nat.Int()
  and would panic on the strconv.ParseUint().  We should (almost) never panic.
- In trying to remove the panic I decided to make it so that we, instead,
  checked the string during the NewPort() constructor.  This means that
  I had to change all casts from 'string' to 'Port' to use NewPort() instead.
  Which is a good thing anyway, people shouldn't assume they know the
  internal format of types like that, in general.
- This meant I had to go and add error checks on all calls to NewPort().
  To avoid changing the testcases too much I create newPortNoError() **JUST**
  for the testcase uses where we know the port string is ok.
- After all of that I then went back and added a check during container.create()
  to check the port string so we'll report the error as soon as we get the
  data.
- If, somehow, the bad string does get into the metadata we will generate
  an error during container.start() but I can't test for that because
  the container.create() catches it now.  But I did add a testcase for that.

Signed-off-by: Doug Davis <[email protected]>
@duglin
Copy link
Copy Markdown
Contributor Author

duglin commented Jul 17, 2015

Updated per @cpuguy83 's suggestion

@duglin
Copy link
Copy Markdown
Contributor Author

duglin commented Jul 21, 2015

ping @cpuguy83 @LK4D4

@calavera
Copy link
Copy Markdown
Contributor

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants