Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

connection.c

Blame
    • Robert Haas's avatar
      ab3f008a
      postgres_fdw: Judge password use by run-as user, not session user. · ab3f008a
      Robert Haas authored
      This is a backward incompatibility which should be noted in the
      release notes for PostgreSQL 11.
      
      For security reasons, we require that a postgres_fdw foreign table use
      password authentication when accessing a remote server, so that an
      unprivileged user cannot usurp the server's credentials.  Superusers
      are exempt from this requirement, because we assume they are entitled
      to usurp the server's credentials or, at least, can find some other
      way to do it.
      
      But what should happen when the foreign table is accessed by a view
      owned by a user different from the session user?  Is it the view owner
      that must be a superuser in order to avoid the requirement of using a
      password, or the session user?  Historically it was the latter, but
      this requirement makes it the former instead.  This allows superusers
      to delegate to other users the right to select from a foreign table
      that doesn't use password authentication by creating a view over the
      foreign table and handing out rights to the view.  It is also more
      consistent with the idea that access to a view should use the view
      owner's privileges rather than the session user's privileges.
      
      The upshot of this change is that a superuser selecting from a view
      created by a non-superuser may now get an error complaining that no
      password was used, while a non-superuser selecting from a view
      created by a superuser will no longer receive such an error.
      
      No documentation changes are present in this patch because the
      wording of the documentation already suggests that it works this
      way.  We should perhaps adjust the documentation in the back-branches,
      but that's a task for another patch.
      
      Originally proposed by Jeff Janes, but with different semantics;
      adjusted to work like this by me per discussion.
      
      Discussion: http://postgr.es/m/CA+TgmoaY4HsVZJv5SqEjCKLDwtCTSwXzKpRftgj50wmMMBwciA@mail.gmail.com
      ab3f008a
      History
      postgres_fdw: Judge password use by run-as user, not session user.
      Robert Haas authored
      This is a backward incompatibility which should be noted in the
      release notes for PostgreSQL 11.
      
      For security reasons, we require that a postgres_fdw foreign table use
      password authentication when accessing a remote server, so that an
      unprivileged user cannot usurp the server's credentials.  Superusers
      are exempt from this requirement, because we assume they are entitled
      to usurp the server's credentials or, at least, can find some other
      way to do it.
      
      But what should happen when the foreign table is accessed by a view
      owned by a user different from the session user?  Is it the view owner
      that must be a superuser in order to avoid the requirement of using a
      password, or the session user?  Historically it was the latter, but
      this requirement makes it the former instead.  This allows superusers
      to delegate to other users the right to select from a foreign table
      that doesn't use password authentication by creating a view over the
      foreign table and handing out rights to the view.  It is also more
      consistent with the idea that access to a view should use the view
      owner's privileges rather than the session user's privileges.
      
      The upshot of this change is that a superuser selecting from a view
      created by a non-superuser may now get an error complaining that no
      password was used, while a non-superuser selecting from a view
      created by a superuser will no longer receive such an error.
      
      No documentation changes are present in this patch because the
      wording of the documentation already suggests that it works this
      way.  We should perhaps adjust the documentation in the back-branches,
      but that's a task for another patch.
      
      Originally proposed by Jeff Janes, but with different semantics;
      adjusted to work like this by me per discussion.
      
      Discussion: http://postgr.es/m/CA+TgmoaY4HsVZJv5SqEjCKLDwtCTSwXzKpRftgj50wmMMBwciA@mail.gmail.com