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

os: package variables can be subverted #7885

Open
gopherbot opened this Issue Apr 28, 2014 · 4 comments

Comments

Projects
None yet
4 participants
@gopherbot

gopherbot commented Apr 28, 2014

by glyn.normington:

It is possible to subvert the behaviour of system packages by overwriting their
variables. For instance, it is possible to set the value of os.ErrPermission. This
should not be allowed as it may cause a security exposures and break existing contracts.

See this for an example: http://play.golang.org/p/PQPr9jcLqU
@cznic

This comment has been minimized.

Show comment
Hide comment
@cznic

cznic Apr 28, 2014

Contributor

Comment 1:

Is there a specific language change proposal available? If so -> ML.
Contributor

cznic commented Apr 28, 2014

Comment 1:

Is there a specific language change proposal available? If so -> ML.
@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Apr 28, 2014

Comment 2 by glyn.normington:

No language change is proposed. Removing all variables from system packages would be a
sufficient, albeit disruptive, fix.
(Broading the meaning of const may be a possible solution too, but I'll leave that to
the experts to decide.)

gopherbot commented Apr 28, 2014

Comment 2 by glyn.normington:

No language change is proposed. Removing all variables from system packages would be a
sufficient, albeit disruptive, fix.
(Broading the meaning of const may be a possible solution too, but I'll leave that to
the experts to decide.)
@ianlancetaylor

This comment has been minimized.

Show comment
Hide comment
@ianlancetaylor

ianlancetaylor Apr 28, 2014

Contributor

Comment 3:

This is not a security issue in the usual sense.  It permits your source code to do bad
things--but your source code can already import unsafe.

Labels changed: added repo-main, release-none.

Status changed to Thinking.

Contributor

ianlancetaylor commented Apr 28, 2014

Comment 3:

This is not a security issue in the usual sense.  It permits your source code to do bad
things--but your source code can already import unsafe.

Labels changed: added repo-main, release-none.

Status changed to Thinking.

@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Apr 29, 2014

Comment 4 by glyn.normington:

Agreed it's not a conventional security issue.
BTW an alternative error idiom which avoid this issue is described here (although ignore
the use of stack traces which wouldn't necessarily be applicable to system libraries):
http://underlap.blogspot.co.uk/2014/04/better-golang-error-idiom.html

gopherbot commented Apr 29, 2014

Comment 4 by glyn.normington:

Agreed it's not a conventional security issue.
BTW an alternative error idiom which avoid this issue is described here (although ignore
the use of stack traces which wouldn't necessarily be applicable to system libraries):
http://underlap.blogspot.co.uk/2014/04/better-golang-error-idiom.html

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

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