text/template: access to methods that are not part of interface

[sorcix]

What version of Go are you using (go version)?

$ go version
go version go1.13.3 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/vic/.cache/go-build"
GOENV="/home/vic/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/vic/Go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build611773016=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.13.3 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.13.3
uname -sr: Linux 5.3.6-arch1-1-ARCH
LSB Version:	1.4
Distributor ID:	Arch
Description:	Arch Linux
Release:	rolling
Codename:	n/a
/usr/lib/libc.so.6: GNU C Library (GNU libc) stable release version 2.30.

What did you do?

I executed a text/template.Template with an interface as data.

Example code

package main

import (
	"os"
	"text/template"
)

type Foo struct {
	A int
}

func (f Foo) B() int {
	return 2
}

func (f Foo) C() int {
	return 3
}

type Bar interface {
	C() int
}

func main() {
	foo := Foo{A: 1}
	test(foo)
}

func test(bar Bar) {
	tpl := template.Must(template.New("template").Parse("{{ .A }} {{ .B }} {{ .C }}"))
	tpl.Execute(os.Stdout, bar)
}

On play: https://play.golang.org/p/YgMyBPie8kw

What did you expect to see?

My template is using functions that don't exist in the interface, thus I was expecting an error.

What did you see instead?

The template is able to execute functions on the underlying type, exposing functionality I don't want to expose.

I believe the text/template package actually behaved as I would expect in the past. I think the functionality was changed in 167a712.

[mvdan]

Have you been able to verify if old versions of Go behave differently here?

If so, could you use a git bisect to see what commit changed the logic? That can be a good starting point to see if the change was on purpose or not.

[sorcix]

I've found this question on Stack Overflow that indicates that it was different. The code listed in the answer there was removed in 167a712, and checked for an empty interface{} vs an interface that had methods, right? I hope to have time next weekend to try out some older Go versions.

Apart from how older versions behaved, it's weird to explicitly pass an interface as data to a template and see it being ignored and the underlying type used instead. It could even be a security issue, as templates have access to more than was intended. (The html/template documentation states "this package assumes that template authors are trusted", but the text/template documentation does not.)

[seankhliao]

Doesn't seem to be much of a problem, you could do this in normal code too with interface assertions...

[sorcix]

Sad to see this security issue is ignored.

You could do this in normal code, but end users may be able to edit the template source while they're not able to edit normal code.

Please at least add a similar note to text/template then, like there is in html/template:

this package assumes that template authors are trusted

(Even better would be to document the security implications of using interfaces as the data parameter.)

There are a lot of use cases for end users to be able to edit templates. Website editors, customizable notifications, e-mails. The documentation should reflect that text/template is not safe for that use case.