etcd/etcdserver/etcdserverpb/raft_internal.proto

76 lines
2.3 KiB
Protocol Buffer
Raw Normal View History

2015-08-08 15:29:18 +03:00
syntax = "proto3";
package etcdserverpb;
import "gogoproto/gogo.proto";
2015-08-08 15:29:18 +03:00
import "etcdserver.proto";
import "rpc.proto";
option (gogoproto.marshaler_all) = true;
option (gogoproto.sizer_all) = true;
option (gogoproto.unmarshaler_all) = true;
option (gogoproto.goproto_getters_all) = false;
message RequestHeader {
uint64 ID = 1;
// username is a username that is associated with an auth token of gRPC connection
string username = 2;
auth, etcdserver: introduce revision of authStore for avoiding TOCTOU problem This commit introduces revision of authStore. The revision number represents a version of authStore that is incremented by updating auth related information. The revision is required for avoiding TOCTOU problems. Currently there are two types of the TOCTOU problems in v3 auth. The first one is in ordinal linearizable requests with a sequence like below (): 1. Request from client CA is processed in follower FA. FA looks up the username (let it U) for the request from a token of the request. At this time, the request is authorized correctly. 2. Another request from client CB is processed in follower FB. CB is for changing U's password. 3. FB forwards the request from CB to the leader before FA. Now U's password is updated and the request from CA should be rejected. 4. However, the request from CA is processed by the leader because authentication is already done in FA. For avoiding the above sequence, this commit lets etcdserverpb.RequestHeader have a member revision. The member is initialized during authentication by followers and checked in a leader. If the revision in RequestHeader is lower than the leader's authStore revision, it means a sequence like above happened. In such a case, the state machine returns auth.ErrAuthRevisionObsolete. The error code lets nodes retry their requests. The second one, a case of serializable range and txn, is more subtle. Because these requests are processed in follower directly. The TOCTOU problem can be caused by a sequence like below: 1. Serializable request from client CA is processed in follower FA. At first, FA looks up the username (let it U) and its permission before actual access to KV. 2. Another request from client CB is processed in follower FB and forwarded to the leader. The cluster including FA now commits a log entry of the request from CB. Assume the request changed the permission or password of U. 3. Now the serializable request from CA is accessing to KV. Even if the access is allowed at the point of 1, now it can be invalid because of the change introduced in 2. For avoiding the above sequence, this commit lets the functions of serializable requests (EtcdServer.Range() and EtcdServer.Txn()) compare the revision in the request header with the latest revision of authStore after the actual access. If the saved revision is lower than the latest one, it means the permission can be changed. Although it would introduce false positives (e.g. changing other user's password), it prevents the TOCTOU problem. This idea is an implementation of Anthony's comment: https://github.com/coreos/etcd/pull/5739#issuecomment-228128254
2016-06-23 12:31:12 +03:00
// auth_revision is a revision number of auth.authStore. It is not related to mvcc
uint64 auth_revision = 3;
}
2015-08-08 15:29:18 +03:00
// An InternalRaftRequest is the union of all requests which can be
// sent via raft.
message InternalRaftRequest {
RequestHeader header = 100;
uint64 ID = 1;
Request v2 = 2;
RangeRequest range = 3;
PutRequest put = 4;
DeleteRangeRequest delete_range = 5;
TxnRequest txn = 6;
2015-09-06 02:08:58 +03:00
CompactionRequest compaction = 7;
LeaseGrantRequest lease_grant = 8;
LeaseRevokeRequest lease_revoke = 9;
AlarmRequest alarm = 10;
LeaseCheckpointRequest lease_checkpoint = 11;
AuthEnableRequest auth_enable = 1000;
AuthDisableRequest auth_disable = 1011;
2016-06-07 06:17:28 +03:00
InternalAuthenticateRequest authenticate = 1012;
2016-06-07 06:17:28 +03:00
AuthUserAddRequest auth_user_add = 1100;
AuthUserDeleteRequest auth_user_delete = 1101;
AuthUserGetRequest auth_user_get = 1102;
AuthUserChangePasswordRequest auth_user_change_password = 1103;
AuthUserGrantRoleRequest auth_user_grant_role = 1104;
AuthUserRevokeRoleRequest auth_user_revoke_role = 1105;
AuthUserListRequest auth_user_list = 1106;
AuthRoleListRequest auth_role_list = 1107;
2016-06-07 06:17:28 +03:00
AuthRoleAddRequest auth_role_add = 1200;
AuthRoleDeleteRequest auth_role_delete = 1201;
AuthRoleGetRequest auth_role_get = 1202;
AuthRoleGrantPermissionRequest auth_role_grant_permission = 1203;
AuthRoleRevokePermissionRequest auth_role_revoke_permission = 1204;
}
message EmptyResponse {
2015-08-08 15:29:18 +03:00
}
// What is the difference between AuthenticateRequest (defined in rpc.proto) and InternalAuthenticateRequest?
// InternalAuthenticateRequest has a member that is filled by etcdserver and shouldn't be user-facing.
// For avoiding misusage the field, we have an internal version of AuthenticateRequest.
message InternalAuthenticateRequest {
string name = 1;
string password = 2;
// simple_token is generated in API layer (etcdserver/v3_server.go)
string simple_token = 3;
}