On Sat, 2021-11-20 at 16:16 -0500, Tom Lane wrote: > One more point is that the proposed business about > > * ImpersonateDatabaseUser will either succeed silently (0-RTT), or > fail. Upon failure, no further commands will be processed until > ImpersonateDatabaseUser succeeds. > > seems to require adding a huge amount of complication on the server side, > and complication in the protocol spec itself, to save a rather minimal > amount of complication in the middleware. Why can't we just say that > a failed "impersonate" command leaves the session in the same state > as before, and it's up to the pooler to do something about it? We are > in any case trusting the pooler not to send commands from user A to > a session logged in as user B.
When combined with the 0-RTT goal, I think a silent ignore would just invite more security problems. Todd is effectively proposing packet pipelining, so the pipeline has to fail shut. A more modern approach might be to attach the authentication to the packet itself (e.g. cryptographically, with a MAC), if the goal is to enable per-statement authentication anyway. In theory that turns the middleware into a message passer instead of a confusable deputy. But it requires more complicated setup between the client and server. > PS: I wonder how we test such a feature meaningfully without > incorporating a pooler right into the Postgres tree. I don't > want to do that, for sure. Having protocol-level tests for bytes on the wire would not only help proposals like this but also get coverage for a huge number of edge cases. Magnus has added src/test/protocol for the server, written in Perl, in his PROXY proposal. And I've added a protocol suite for both the client and server, written in Python/pytest, in my OAuth proof of concept. I think something is badly needed in this area. --Jacob
