Setting or getting an unsupported option should return an error

[arthurpi]

Description

Applicable to transport/internal/network.NetworkEndpoint (=> udp & raw & icmp endpoints) transport/tcp.Endpoint

Some of the methods to set or get an option {Get,Set}SockOpt{,Int} do not return an error when an unknown option (meaning: an option not supported on that specific endpoint) is given.

Behavior is inconsistent: Some of these do return an error. Some don't.

This was probably introduced by error, because most (or all) used to return errors. For example, see https://github.com/google/gvisor/commit/7928aa345e334f2c68f8f03b71d8cabe79e8db7e#diff-c9e1658507f02e1efbbe963ae4cb54b3707965c9bfcf1c0a55d9562a1f9ff61bR1481

Steps to reproduce

No response

runsc version

No response

docker version (if using docker)

No response

uname

No response

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

No response

[hbhasker]

So you have to be careful with this returning errors for some of these can cause applications on gvisor to misbehave whereas on linux the getsockopt/setsockopt is never expected to return an error. Just something to keep in mind when changing these.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 120 days.

[github-actions[bot]]

This issue has been closed due to lack of activity.