{"push_id":1211067500,"size":1,"distinct_size":1,"ref":"refs/heads/auth-revision","head":"eaa06e132847ab9e71c2cfaeba40398c045de483","before":"af1a946b7151e800b74839177699b299fb698608","commits":[{"sha":"eaa06e132847ab9e71c2cfaeba40398c045de483","author":{"name":"Hitoshi Mitake","email":"5b2187c33a904b291d57dc5560a08df5e7ab946d@lab.ntt.co.jp"},"message":"auth, etcdserver: introduce revision of authStore for avoiding TOCTOU problem\n\nThis commit introduces revision of authStore. The revision number\nrepresents a version of authStore that is incremented by updating auth\nrelated information.\n\nThe revision is required for avoiding TOCTOU problems. Currently there\nare two types of the TOCTOU problems in v3 auth.\n\nThe first one is in ordinal linearizable requests with a sequence like\nbelow ():\n1. Request from client CA is processed in follower FA. FA looks up the\n   username (let it U) for the request from a token of the request. At\n   this time, the request is authorized correctly.\n2. Another request from client CB is processed in follower FB. CB\n   is for changing U's password.\n3. FB forwards the request from CB to the leader before FA. Now U's\n   password is updated and the request from CA should be rejected.\n4. However, the request from CA is processed by the leader because\n   authentication is already done in FA.\n\nFor avoiding the above sequence, this commit lets\netcdserverpb.RequestHeader have a member revision. The member is\ninitialized during authentication by followers and checked in a\nleader. If the revision in RequestHeader is lower than the leader's\nauthStore revision, it means a sequence like above happened. In such a\ncase, the state machine returns auth.ErrAuthRevisionObsolete. The\nerror code lets nodes retry their requests.\n\nThe second one, a case of serializable range and txn, is more\nsubtle. Because these requests are processed in follower directly. The\nTOCTOU problem can be caused by a sequence like below:\n1. Serializable request from client CA is processed in follower FA. At\n   first, FA looks up the username (let it U) and its permission\n   before actual access to KV.\n2. Another request from client CB is processed in follower FB and\n   forwarded to the leader. The cluster including FA now commits a log\n   entry of the request from CB. Assume the request changed the\n   permission or password of U.\n3. Now the serializable request from CA is accessing to KV. Even if\n   the access is allowed at the point of 1, now it can be invalid\n   because of the change introduced in 2.\n\nFor avoiding the above sequence, this commit lets the functions of\nserializable requests (EtcdServer.Range() and EtcdServer.Txn())\ncompare the revision in the request header with the latest revision of\nauthStore after the actual access. If the saved revision is lower than\nthe latest one, it means the permission can be changed. Although it\nwould introduce false positives (e.g. changing other user's password),\nit prevents the TOCTOU problem. This idea is an implementation of\nAnthony's comment:\nhttps://github.com/coreos/etcd/pull/5739#issuecomment-228128254","distinct":true,"url":"https://api.github.com/repos/mitake/etcd/commits/eaa06e132847ab9e71c2cfaeba40398c045de483"}]}
{"actor":{"display_login":"mitake"}}