Details
-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
3
-
8148
Description
In order to avoid malicious clients to replay RPCs that were previously sent and correctly signed, the server should reject RPCs that have XIDs that are "too old".
As for what constitutes "too old", the ideal implementation would reject any RPC XID that had been completed, but this will likely impose an undue burden of complexity on the server to track every XID from the client, and determine that the client had received the RPC reply. Since the client XID stream for any particular server is sparse, it would be difficult to know exactly when the server can assume that a particular XID will no longer be sent.
There is the added complexity that in the face of a server crash, the client will need to replay and resend a number of RPC XIDs in order to fix up any server state that was not committed to disk. Also important to note is that the current client code will replay open RPCs during recovery, and these may have an arbitrarily old XID value.
Instead, I would propose a somewhat relaxed XID tracking mechanism that expires RPC XIDs older than "X" after some interval. RPCs that are not marked MSG_REPLAY or MSG_RESEND with XID < X should be rejected.
For open requests, we've previously discussed for the "Simplified Interoperability" project to avoid using the ptlrpc replay mechanism for re-opening files, since this forces the client to replay open RPCs against a server that might be using a new protocol. It doesn't make sense to keep these RPCs for replay after their corresponding "create" transaction has been committed. Until that is implemented, the open replay RPCs with old XIDs would need to be allowed, or the client could update the XIDs in the replayed RPCs to be "new enough" so that they are accepted.
