os: package variables can be subverted

[gopherbot]

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]

Comment 1:

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

[cznic]

Comment 1:

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

[gopherbot]

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]

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]

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.

[ianlancetaylor]

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]

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]

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