You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that when auth_to_local_names is specified in the krb5 config parsing results in a panic.
For example adding this to a realm in the test krb5Conf (v8/config/krb5conf_test.go):
auth_to_local_names= {
name=othername
}
Results in:
[antbbn@fedora config]$ go test
--- FAIL: TestResolveRealm (0.00s)
panic: runtime error: index out of range [1] with length 1 [recovered]
panic: runtime error: index out of range [1] with length 1
goroutine 34 [running]:
testing.tRunner.func1.2({0x5f6200, 0xc000252030})
/usr/lib/golang/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
/usr/lib/golang/src/testing/testing.go:1634 +0x377
panic({0x5f6200?, 0xc000252030?})
/usr/lib/golang/src/runtime/panic.go:770 +0x132
github.com/jcmturner/gokrb5/v8/config.(*Realm).parseLines(0xc0003177f8, {0xc0000ac631?, 0x66f2c8?}, {0xc0002701d8?, 0x0?, 0xc00009c370?})
/home/antbbn/gokrb5/v8/config/krb5conf.go:379 +0xdfe
github.com/jcmturner/gokrb5/v8/config.parseRealms({0xc000270118, 0x1a, 0x36})
/home/antbbn/gokrb5/v8/config/krb5conf.go:447 +0x39e
github.com/jcmturner/gokrb5/v8/config.NewFromScanner(0xc000317d90)
/home/antbbn/gokrb5/v8/config/krb5conf.go:591 +0x79e
github.com/jcmturner/gokrb5/v8/config.NewFromReader({0x6709e0?, 0xc0004d76c0?})
/home/antbbn/gokrb5/v8/config/krb5conf.go:537 +0x68
github.com/jcmturner/gokrb5/v8/config.NewFromString({0x61c065, 0x6e4})
/home/antbbn/gokrb5/v8/config/krb5conf.go:531 +0x6f
github.com/jcmturner/gokrb5/v8/config.TestResolveRealm(0xc000208000)
/home/antbbn/gokrb5/v8/config/krb5conf_test.go:644 +0x3b
testing.tRunner(0xc000208000, 0x637cb8)
/usr/lib/golang/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
/usr/lib/golang/src/testing/testing.go:1742 +0x390
exit status 2
FAIL github.com/jcmturner/gokrb5/v8/config 0.020s
The issue seems to stem from the fact that in parseLines when a line with a single } is encountered and the section was not explictly ignored (eg. ignore = true) the line is split and the second element is accessed.
The following diff fixes the issue for my test case and, looking at the docs, I don't think there are other non v4 subsections in [realms] (v4 ones are correctly ignored). Not sure if the panic can be triggered in other sections of krb5.conf.
If you would like me to make a PR i'll be happy to.
diff --git a/v8/config/krb5conf.go b/v8/config/krb5conf.go
index f448c8a..7c7f36e 100644
--- a/v8/config/krb5conf.go+++ b/v8/config/krb5conf.go@@ -354,6 +354,9 @@ func (r *Realm) parseLines(name string, lines []string) (err error) {
ignore = true
err = UnsupportedDirective{"v4 configurations are not supported"}
}
+ if strings.Contains(line, "auth_to_local_names") {+ ignore = true+ }
if strings.Contains(line, "{") {
c++
if ignore {
Some details:
gokrb5 version: master and 8.4.4
go version: go version go1.22.11 linux/amd64 (was unable to install an earlier one)
environment: not relevant for this issue
The text was updated successfully, but these errors were encountered:
I noticed that when
auth_to_local_names
is specified in the krb5 config parsing results in a panic.For example adding this to a realm in the test
krb5Conf
(v8/config/krb5conf_test.go):Results in:
The issue seems to stem from the fact that in parseLines when a line with a single
}
is encountered and the section was not explictly ignored (eg.ignore = true
) the line is split and the second element is accessed.The following diff fixes the issue for my test case and, looking at the docs, I don't think there are other non v4 subsections in
[realms]
(v4 ones are correctly ignored). Not sure if the panic can be triggered in other sections of krb5.conf.If you would like me to make a PR i'll be happy to.
Some details:
gokrb5 version: master and 8.4.4
go version: go version go1.22.11 linux/amd64 (was unable to install an earlier one)
environment: not relevant for this issue
The text was updated successfully, but these errors were encountered: