Skip to content
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

signCSRs panics if record for attested node is not found #682

Closed
ZymoticB opened this issue Jan 18, 2019 · 0 comments
Closed

signCSRs panics if record for attested node is not found #682

ZymoticB opened this issue Jan 18, 2019 · 0 comments
Assignees

Comments

@ZymoticB
Copy link
Contributor

  • Version: A couple of commits on top of 9117b6d. Changes unrelated to spire-server.
  • Platform: Linux 4.9.0-8-amd64 CLI authentication #1 SMP Debian 4.9.110-3+deb9u3 (2018-08-19) x86_64 GNU/Linux
  • Subsystem: spire-server
Jan 18 20:23:09 <hostname> spire-server[9781]: panic: runtime error: invalid memory address or nil pointer dereference
Jan 18 20:23:09 <hostname> spire-server[9781]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xe894e5]
Jan 18 20:23:09 <hostname> spire-server[9781]: goroutine 283 [running]:
Jan 18 20:23:09 <hostname>spire-server[9781]: github.com/spiffe/spire/pkg/server/endpoints/node.(*Handler).signCSRs(0xc0003240e0, 0x13f7820, 0xc0003b7410, 0xc000160100, 0xc000308d00, 0x1, 0x1, 0x0, 0x0, 0x0, ...)
Jan 18 20:23:09 <hostname> spire-server[9781]:         /home/prodadmin/spire/pkg/server/endpoints/node/handler.go:631 +0x6b5
Jan 18 20:23:09 <hostname> spire-server[9781]: github.com/spiffe/spire/pkg/server/endpoints/node.(*Handler).FetchX509SVID(0xc0003240e0, 0x13fc1e0, 0xc0006c1c40, 0x0, 0x0)
Jan 18 20:23:09 <hostname> spire-server[9781]:         /home/prodadmin/spire/pkg/server/endpoints/node/handler.go:218 +0x529
Jan 18 20:23:09 <hostname> spire-server[9781]: github.com/spiffe/spire/proto/api/node._Node_FetchX509SVID_Handler(0x12459e0, 0xc0003240e0, 0x13fb220, 0xc000308cc0, 0xc000486000, 0x22)
Jan 18 20:23:09 <hostname> spire-server[9781]:         /home/prodadmin/spire/proto/api/node/node.pb.go:767 +0xad
Jan 18 20:23:09 <hostname> spire-server[9781]: github.com/spiffe/spire/pkg/common/auth.StreamAuthorizeCall(0x12459e0, 0xc0003240e0, 0x13faec0, 0xc00015c370, 0xc000308c80, 0x12e4788, 0x6e52205fbbfdd81d, 0x0)
Jan 18 20:23:09 <hostname> spire-server[9781]:         /home/prodadmin/spire/pkg/common/auth/interceptors.go:35 +0x137
Jan 18 20:23:09 <hostname> spire-server[9781]: google.golang.org/grpc.(*Server).processStreamingRPC(0xc000166a80, 0x13fd7a0, 0xc0001b6800, 0xc000237000, 0xc000137dd0, 0x20324e0, 0x0, 0x0, 0x0)
Jan 18 20:23:09 <hostname>spire-server[9781]:         /home/prodadmin/gopath/pkg/mod/google.golang.org/grpc@v1.14.0/server.go:1175 +0x440
Jan 18 20:23:09 <hostname> spire-server[9781]: google.golang.org/grpc.(*Server).handleStream(0xc000166a80, 0x13fd7a0, 0xc0001b6800, 0xc000237000, 0x0)
Jan 18 20:23:09 <hostname> spire-server[9781]:         /home/prodadmin/gopath/pkg/mod/google.golang.org/grpc@v1.14.0/server.go:1256 +0x12aa
Jan 18 20:23:09 <hostname> spire-server[9781]: google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc000032560, 0xc000166a80, 0x13fd7a0, 0xc0001b6800, 0xc000237000)
Jan 18 20:23:09 <hostname> spire-server[9781]:         /home/prodadmin/gopath/pkg/mod/google.golang.org/grpc@v1.14.0/server.go:699 +0x9f
Jan 18 20:23:09 <hostname> spire-server[9781]: created by google.golang.org/grpc.(*Server).serveStreams.func1
Jan 18 20:23:09 <hostname> spire-server[9781]:         /home/prodadmin/gopath/pkg/mod/google.golang.org/grpc@v1.14.0/server.go:697 +0xa1

This was admittedly likely caused by deletion of the data dir as some engineers were working concurrently and not communicating.

It seems to me that this was caused by the record for an attested node not existing

			res, err := dataStore.FetchAttestedNode(ctx,
				&datastore.FetchAttestedNodeRequest{SpiffeId: spiffeID},
			)
			if err != nil {
				return nil, err
			}
			if res.Node.CertSerialNumber != peerCert.SerialNumber.String() {
				err := errors.New("SVID serial number does not match")
				return nil, err
			}

I don't think this is possible right now other than there being data loss in the DB, but, this code shouldn't panic regardless of the unlikelyness of that event. Additionally, this will be relevant in implementing eviction (#27)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants