On Wed, Dec 05, 2018 at 11:20:52PM -0800, Noah Misch wrote:
> On Thu, Aug 30, 2018 at 12:06:09AM -0700, Noah Misch wrote:
> > On Sat, Aug 11, 2018 at 12:47:05PM -0700, Noah Misch wrote:
> > > On Wed, Aug 08, 2018 at 09:58:38AM -0400, Tom Lane wrote:
> > > > When the security team was discussing
On Thu, Aug 30, 2018 at 12:06:09AM -0700, Noah Misch wrote:
> On Sat, Aug 11, 2018 at 12:47:05PM -0700, Noah Misch wrote:
> > On Wed, Aug 08, 2018 at 09:58:38AM -0400, Tom Lane wrote:
> > > When the security team was discussing this issue before, we speculated
> > > about ideas like inventing a
On Sat, Aug 11, 2018 at 12:47:05PM -0700, Noah Misch wrote:
> On Wed, Aug 08, 2018 at 09:58:38AM -0400, Tom Lane wrote:
> > When the security team was discussing this issue before, we speculated
> > about ideas like inventing a function trust mechanism, so that attacks
> > based on search path
On Thu, Aug 16, 2018 at 10:58:21PM -0400, Chapman Flack wrote:
> On 08/16/18 21:31, Bruce Momjian wrote:
>
> > I understand you don't like that a search_path changed by a function is
> > passed down to functions it calls, but what would you like the system to
> > use as a search path for called
On 08/16/18 21:31, Bruce Momjian wrote:
> I understand you don't like that a search_path changed by a function is
> passed down to functions it calls, but what would you like the system to
> use as a search path for called functions? The search path of the
> session?
This is beginning to sound
On Thu, Aug 16, 2018 at 03:46:06PM -0400, Robert Haas wrote:
> On Wed, Aug 15, 2018 at 3:17 PM, Bruce Momjian wrote:
> > On Wed, Aug 15, 2018 at 11:05:06AM -0400, Robert Haas wrote:
> >> On Tue, Aug 14, 2018 at 4:42 PM, Bruce Momjian wrote:
> >> > So you are saying PG functions should lock down
On Thu, Aug 16, 2018 at 12:27 AM, Tom Lane wrote:
> Mark Dilger writes:
>> Go ahead and define some new lexical scope mechanism. I'm probably
>> going to move into the 21st century with you and use it. (I mostly
>> use "my", not "local", when I write perl code.) But let's treat that as
>> a
On Wed, Aug 15, 2018 at 3:17 PM, Bruce Momjian wrote:
> On Wed, Aug 15, 2018 at 11:05:06AM -0400, Robert Haas wrote:
>> On Tue, Aug 14, 2018 at 4:42 PM, Bruce Momjian wrote:
>> > So you are saying PG functions should lock down their search path at
>> > function definition time, and use that for
> On Aug 15, 2018, at 9:27 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Go ahead and define some new lexical scope mechanism. I'm probably
>> going to move into the 21st century with you and use it. (I mostly
>> use "my", not "local", when I write perl code.) But let's treat that as
>>
On Wed, Aug 15, 2018 at 10:40:55AM -0500, Nico Williams wrote:
> On Tue, Aug 14, 2018 at 11:50:24PM +, Nasby, Jim wrote:
> > On Aug 14, 2018, at 4:01 PM, Nico Williams wrote:
> > >
> > > On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
> > >> The more I think about it, the more I
On Wed, Aug 15, 2018 at 12:04:53PM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 10:44 PM, Noah Misch wrote:
> > Right. For what it's worth, the example I permuted upthread might look like
> > this in a lexical search path world:
> >
> > -- Always secure, even if schema usage does not
Mark Dilger writes:
> Go ahead and define some new lexical scope mechanism. I'm probably
> going to move into the 21st century with you and use it. (I mostly
> use "my", not "local", when I write perl code.) But let's treat that as
> a new feature independent of fixing the security problems
> On Aug 15, 2018, at 9:02 AM, Robert Haas wrote:
>
> On Tue, Aug 14, 2018 at 5:14 PM, Mark Dilger wrote:
>> I think you are interpreting the problem too broadly. This is basically
>> just a privilege escalation attack vector.
>
> Hmm. Well, I think you're interpreting the problem too
On Wed, Aug 15, 2018 at 11:05:06AM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 4:42 PM, Bruce Momjian wrote:
> > So you are saying PG functions should lock down their search path at
> > function definition time, and use that for all function invocations?
>
> Yes, mostly. I don't think
On Tue, Aug 14, 2018 at 10:44 PM, Noah Misch wrote:
> Right. For what it's worth, the example I permuted upthread might look like
> this in a lexical search path world:
>
> -- Always secure, even if schema usage does not conform to
> ddl-schemas-patterns
> -- and function trust is disabled or
On Tue, Aug 14, 2018 at 5:14 PM, Mark Dilger wrote:
> I think you are interpreting the problem too broadly. This is basically
> just a privilege escalation attack vector.
Hmm. Well, I think you're interpreting the problem too narrowly. :-)
In my view, the problem isn't just that there is a
On Tue, Aug 14, 2018 at 11:50:24PM +, Nasby, Jim wrote:
> On Aug 14, 2018, at 4:01 PM, Nico Williams wrote:
> >
> > On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
> >> The more I think about it, the more I think having a way to set a
> >> lexically-scoped search path is
On Tue, Aug 14, 2018 at 4:42 PM, Bruce Momjian wrote:
> So you are saying PG functions should lock down their search path at
> function definition time, and use that for all function invocations?
Yes, mostly. I don't think we can just change the existing behavior;
it would break a catastrophic
On Tue, Aug 14, 2018 at 04:42:43PM -0400, Bruce Momjian wrote:
> On Tue, Aug 14, 2018 at 04:23:33PM -0400, Robert Haas wrote:
> > On Tue, Aug 14, 2018 at 3:31 PM, Bruce Momjian wrote:
> > > I am unclear how lexical scoping helps with this, or with Postgres.
> >
> > Well, if you say sqrt(x) in C,
On 08/14/2018 07:01 PM, Nico Williams wrote:
> On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
>> The more I think about it, the more I think having a way to set a
>> lexically-scoped search path is probably the answer. [...]
>
> Yes please!
>
> This is what I want. Evaluate the
On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
> The more I think about it, the more I think having a way to set a
> lexically-scoped search path is probably the answer. [...]
Yes please!
This is what I want. Evaluate the search_path at function definition
time, and record code
> On Aug 14, 2018, at 8:00 AM, Robert Haas wrote:
>
> On Wed, Aug 8, 2018 at 1:58 PM, Tom Lane wrote:
>> I'm not sold on #2 either. That path leads to, for example,
>> s/=/OPERATOR(pg_catalog.=)/g everywhere, which is utterly catastrophic
>> to both readability and portability of your SQL
On Tue, Aug 14, 2018 at 04:23:33PM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 3:31 PM, Bruce Momjian wrote:
> > Well, in C, if the calling function is not in the current C file, you
> > really don't know what function you are linking to --- it depends on
> > what other object files are
On Tue, Aug 14, 2018 at 3:31 PM, Bruce Momjian wrote:
> Well, in C, if the calling function is not in the current C file, you
> really don't know what function you are linking to --- it depends on
> what other object files are linked into the executable.
True.
> I am unclear how lexical scoping
On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
> The more I think about it, the more I think having a way to set a
> lexically-scoped search path is probably the answer. Many years ago,
> Perl had only "local" as a way of declaring local variables, which
> used dynamic scoping, and
On Wed, Aug 8, 2018 at 1:58 PM, Tom Lane wrote:
> I'm not sold on #2 either. That path leads to, for example,
> s/=/OPERATOR(pg_catalog.=)/g everywhere, which is utterly catastrophic
> to both readability and portability of your SQL code. We *must* find
> a way to do better, not tell people
On Sat, Aug 11, 2018 at 03:32:23PM -0500, Nico Williams wrote:
> On Sat, Aug 11, 2018 at 12:47:05PM -0700, Noah Misch wrote:
> > -- (3) "SET search_path" with today's code.
> > --
> > -- Security and reliability considerations are the same as (2). Today, this
> > -- reduces performance by
On Wed, Aug 08, 2018 at 10:47:04AM -0400, Tom Lane wrote:
> Isaac Morland writes:
> > While I'm asking, does anybody know why this isn't the default, especially
> > for SECURITY DEFINER functions?
>
> It might fix some subset of security issues, but I think that changing
> the default behavior
On Sat, Aug 11, 2018 at 12:47:05PM -0700, Noah Misch wrote:
> -- (3) "SET search_path" with today's code.
> --
> -- Security and reliability considerations are the same as (2). Today, this
> -- reduces performance by suppressing optimizations like inlining.
Out of curiosity, why does this
On Wed, Aug 08, 2018 at 09:58:38AM -0400, Tom Lane wrote:
> I'm not sold on #2 either. That path leads to, for example,
> s/=/OPERATOR(pg_catalog.=)/g everywhere, which is utterly catastrophic
> to both readability and portability of your SQL code. We *must* find
> a way to do better, not tell
Mark Dilger writes:
> On Aug 8, 2018, at 7:47 AM, Tom Lane wrote:
>> The advantage of a function trust mechanism is that it'd provide
>> security against calling functions you didn't intend to without
>> any visible changes in normal application behavior. The security
>> team gave up on that
> On Aug 8, 2018, at 7:47 AM, Tom Lane wrote:
>
> Isaac Morland writes:
>> On 8 August 2018 at 09:58, Tom Lane wrote:
>>> When the security team was discussing this issue before, we speculated
>>> about ideas like inventing a function trust mechanism, so that attacks
>>> based on search path
Isaac Morland writes:
> On 8 August 2018 at 09:58, Tom Lane wrote:
>> When the security team was discussing this issue before, we speculated
>> about ideas like inventing a function trust mechanism, so that attacks
>> based on search path manipulations would fail even if they managed to
>>
On 8 August 2018 at 09:58, Tom Lane wrote:
When the security team was discussing this issue before, we speculated
> about ideas like inventing a function trust mechanism, so that attacks
> based on search path manipulations would fail even if they managed to
> capture an operator reference. I'd
Robert Haas writes:
> +1. Better still would be to invent a way to remove the need for such
> onerous qualification, but I don't have a good idea.
Yeah.
> So I guess what we need is a UI that lets you say either:
> - Don't tell me about anything, or
> - Tell me about all unqualified
On Wed, Aug 08, 2018 at 12:00:45PM +0530, Robert Haas wrote:
> On Sun, Aug 5, 2018 at 1:34 PM, Noah Misch wrote:
> > If hackers and non-core extension authors are to write such code, let's make
> > it easier to check the work.
>
> +1. Better still would be to invent a way to remove the need for
On Sun, Aug 5, 2018 at 1:34 PM, Noah Misch wrote:
> If hackers and non-core extension authors are to write such code, let's make
> it easier to check the work.
+1. Better still would be to invent a way to remove the need for such
onerous qualification, but I don't have a good idea.
> a. SQL
37 matches
Mail list logo
