etcd: watch stream return "permission denied" if token expired
i ran into the similar problem as #8914
i’m using v3.4.13 server and v3.4.12 client. i can reproduce the error using following steps:
on one terminal , start etcd server and enable auth and shroten the default token ttl:
etcd --log-level warn --logger zap --auth-token-ttl 10 &
etcdctl user add root:root
etcdctl user grant-role root root
etcdctl auth enable
on the other termianal, run a the demo program:
cfz@cfz-desktop:~/ws/etcd-watch-demo$ cat main.go
package main
import (
"context"
"fmt"
"sync"
"time"
"go.etcd.io/etcd/clientv3"
)
var wg sync.WaitGroup
func main() {
cfg := clientv3.Config{
Endpoints: []string{"http://127.0.0.1:2379"},
Username: "root",
Password: "root",
LogConfig: nil,
}
cli, err := clientv3.New(cfg)
if err != nil {
panic(err)
}
watch(cli, 1)
time.Sleep(1 * time.Second)
watch(cli, 2)
time.Sleep(11 * time.Second)
watch(cli, 3)
time.Sleep(1 * time.Second)
watch(cli, 4)
wg.Wait()
}
func watch(cli *clientv3.Client, num int) {
wg.Add(1)
go func() {
defer wg.Done()
for wr := range cli.Watch(context.Background(), "") {
if wr.Err() != nil {
fmt.Printf("%#v\n", wr.Err())
}
}
fmt.Printf("#%v watch existed\n", num)
}()
}
cfz@cfz-desktop:~/ws/etcd-watch-demo$ go run main.go
&errors.errorString{s:"rpc error: code = PermissionDenied desc = etcdserver: permission denied"}
#3 watch exited
&errors.errorString{s:"rpc error: code = PermissionDenied desc = etcdserver: permission denied"}
#4 watch exited
as shown in the log , the 1st and 2nd watch is ok, while the 3rd and 4th report “permission denied”
meanwile, etcd server will log following:
{"level":"warn","ts":"2020-10-10T20:34:45.010+0800","caller":"auth/store.go:1301","msg":"invalid auth token","token":"JWourXlCoFPTxMHj.8"}
{"level":"warn","ts":"2020-10-10T20:34:46.010+0800","caller":"auth/store.go:1301","msg":"invalid auth token","token":"JWourXlCoFPTxMHj.8"}
i think the causes are:
- the grpc stream’s authentication token is provided at the time when the stream is initialized
- the client is trying to reusing the same grpc stream(if avaliable) to setup new watch substream.
- the token attached to the stream would be expired if no other requests to extend its ttl.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 18 (15 by maintainers)
Commits related to this issue
- client/v3: clear auth token when encounter ErrInvalidAuthToken Old etcdserver which have not apply pr of #12165 will check auth token even if the request is a Authenticate request. If the client has... — committed to bbiao/etcd by bbiao 4 years ago
- client/v3: clear auth token when encounter ErrInvalidAuthToken Old etcdserver which have not apply pr of #12165 will check auth token even if the request is a Authenticate request. If the client has... — committed to bbiao/etcd by bbiao 4 years ago
- client/v3: clear auth token when encounter ErrInvalidAuthToken Old etcdserver which have not apply pr of #12165 will check auth token even if the request is an Authenticate request. If the client ha... — committed to bbiao/etcd by bbiao 4 years ago
- client/v3: clear auth token when encounter ErrInvalidAuthToken Old etcdserver which have not apply pr of #12165 will check auth token even if the request is an Authenticate request. If the client has... — committed to bbiao/etcd by bbiao 4 years ago
- client/v3: clear auth token when encounter ErrInvalidAuthToken Old etcdserver which have not apply pr of #12165 will check auth token even if the request is an Authenticate request. If the client has... — committed to agargi/etcd by bbiao 4 years ago
- Disable auth gracefully without impacting existing watchers This attempts to fix a special case of the problem described in #12385, where trying to do `clientv3.Watch` with an expired token would res... — committed to sayap/etcd by sayap 3 years ago
- Disable auth gracefully without impacting existing watchers This attempts to fix a special case of the problem described in #12385, where trying to do `clientv3.Watch` with an expired token would res... — committed to sayap/etcd by sayap 3 years ago
- clientv3: revert the client side change in 14547 In order to fix https://github.com/etcd-io/etcd/issues/12385, PR https://github.com/etcd-io/etcd/pull/14322 introduced a change in which the client si... — committed to ahrtr/etcd by ahrtr 2 years ago
- clientv3: revert the client side change in 14547 In order to fix https://github.com/etcd-io/etcd/issues/12385, PR https://github.com/etcd-io/etcd/pull/14322 introduced a change in which the client si... — committed to tjungblu/etcd by ahrtr 2 years ago
- clientv3: revert the client side change in 14547 In order to fix https://github.com/etcd-io/etcd/issues/12385, PR https://github.com/etcd-io/etcd/pull/14322 introduced a change in which the client si... — committed to tjungblu/etcd by ahrtr 2 years ago
@838239178 This is expected because retry behavior was reverted. I’ll push an alternative way to handle this as discussed in https://github.com/etcd-io/etcd/issues/15058