Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: net: Add ControlContext to Dialer #55301

Open
pquerna opened this issue Sep 21, 2022 · 3 comments
Open

proposal: net: Add ControlContext to Dialer #55301

pquerna opened this issue Sep 21, 2022 · 3 comments
Labels
Milestone

Comments

@pquerna
Copy link

pquerna commented Sep 21, 2022

The net.Dialer struct contains a the .Control field, a callback. The original intention of this method was to "Permit setting socket options", as noted in the Go 1.11 release notes. One additional use case for this function is a defensive purpose: Preventing some types of Server Side Request Forgery (SSRF) -- as detailed in this blog post:

https://www.agwa.name/blog/post/preventing_server_side_request_forgery_in_golang

In security focused use case, having a variant of the .Control method which received the context.Context would be very helpful:

  1. It would allow propagation of logging contexts, metric context or other metadata down to the callback.
  2. Potentially, the callback could be doing I/O, such as checking with an external service, if a destination is allowed. Today without a context.Context, you don't get cancellation or other context.Values that could be helpful.

Proposed addition to the Dialer struct:

type Dialer struct {
    ControlContext (ctx context.Context, network string, address string, c syscall.RawConn) error
}

Similar to other *Context variants in the standard library, it would only be used if set, and used in preference to the non-context variant.

@gopherbot gopherbot added this to the Proposal milestone Sep 21, 2022
@rsc
Copy link
Contributor

rsc commented Sep 28, 2022

/cc @neild

@neild
Copy link
Contributor

neild commented Sep 28, 2022

Using the Control callback for security controls feels like scope creep; Control was intended for injecting socket options, which is why it's called after the socket is created.

That said, I can think of other cases where it might be useful to pass a Context down to the Control func. We've got a package inside Google which passes socket-level network QoS settings via the Context, for example, and I could imagine having a Control func that sets the QoS based on the context value.

I don't have a strong opinion on whether we should add a ControlContext, but it doesn't seem unreasonable.

@rsc
Copy link
Contributor

rsc commented Sep 28, 2022

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Active
Development

No branches or pull requests

4 participants