This commit adds a new option --from-key to the command etcdctl role
grant-permission. If the option is passed, an open ended permission
will be granted to a role e.g. from start-key to any keys those are
larger than start-key.
Example:
$ ETCDCTL_API=3 bin/etcdctl --user root:p role grant r1 readwrite a b
$ ETCDCTL_API=3 bin/etcdctl --user root:p role grant --from-key r1 readwrite c
$ ETCDCTL_API=3 bin/etcdctl --user root:p role get r1
Role r1
KV Read:
[a, b) (prefix a)
[c, <open ended>
KV Write:
[a, b) (prefix a)
[c, <open ended>
Note that a closed parenthesis doesn't follow the above <open ended>
for indicating that the role has an open ended permission ("<open
ended>" is a valid range end).
Fixes https://github.com/coreos/etcd/issues/7468
This commit change the type of cached permission information from the
home made thing to interval tree. It improves computational complexity
of permission checking from O(n) to O(lg n).
No need of separate function to filter duplicates.
Just merge ranges in-place
```
go test -v -run=xxx -bench=BenchmarkMergeOld -benchmem
BenchmarkMergeOld-8 100000 13524 ns/op 1104 B/op 8 allocs/op
go test -v -run=xxx -bench=BenchmarkMergeNew -benchmem
BenchmarkMergeNew-8 100000 13432 ns/op 936 B/op 3 allocs/op
```
Not much performance boost, but less memory allocation
and simpler
Test 15, counting from zero, in TestGetMergedPerms
in etcd/auth/range_perm_cache_test.go, was trying
incorrectly assert that [a, b) merged with [b, "")
should be [a, b). Added a test specifically for
this. This patch fixes the incorrect larger test
and the bugs in the code that it was hiding.
Fixes#6359
Currently the auth mechanism doesn't support permissions of range
request. It just checks exact matching of key names even for range
queries. This commit adds a mechanism for setting permission to range
queries. Range queries are allowed if a range of the query is [begin1,
end1) and the user has a permission of reading [begin2, range2) and
[begin1, end2) is a subset of [begin2, range2). Range delete requests
will follow the same rule.
Jingyi Hu