[ I wasn't paying much attention to this thread at the time, but
Kyotaro-san just drew my attention to it again ]
Masahiko Sawada <sawada.m...@gmail.com> writes:
> I agree that this feature covers A and B as the first step. But I'm
> concerned that for D (and maybe for C?) the volatility of mapped
> function could be changed. That is, currently we allow to push down
> only immutable functions but they might break it. Also, can the
> replacing a function with any expression be a risk of sql injections?
Yes, I'm afraid that there's serious security issues here that
the SQL standard fails to address. Let's assume that user A has
created a function F(), and user B has created a foreign server S.
What privileges should be required for user C to create a mapping
for F on S? AFAICS, the spec only requires C to have USAGE on S.
This means that all C needs is USAGE on S to create a trojan horse
that will execute arbitrary code when any other user D executes
a query using F on S. C doesn't need to have any privilege on F
at all, and USAGE is not exactly strong privilege on S --- you
certainly wouldn't expect that "USAGE" translates to "I can
backdoor anybody else's usage of this server".
I see that SQL:2011's access rules for "CREATE ROUTINE MAPPING" are
1) The applicable privileges shall include the USAGE privilege on
the foreign server identified by FSN.
2) Additional privileges, if any, necessary to execute <routine
mapping definition> are implementation-defined.
It seems to me that (2) should be read as "we know we blew it here,
but we're leaving it up to implementors to fix this".
Some of the alternatives that were discussed upthread basically replace
this whole idea with attaching properties to the original function F.
I think I like that a lot better from a security perspective. If you are
calling F in your query, you are already placing trust in F's owner.
Better to let F's owner define how it maps to functions on remote servers
than to let random third parties define that.
regards, tom lane
