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 thi
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 fun
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 mani
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 fu
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 l
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 t
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 ne
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 a
> 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
>> a
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 confo
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 wit
> 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 narr
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 we
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 un
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 ri
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 probably
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 a
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 se
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 wi
> 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 co
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 li
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 t
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 that
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 suppress
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 li
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 suppres
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 pe
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 app
> 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
>> captur
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 references
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 int
Commit e09144e documented the rules for writing safe qualified names, but
those rules are tedious to apply in practice. Spotting the defects in this
function definition (from an unpublished draft intended for
https://postgr.es/m/20180710014308.ga805...@rfd.leadboat.com) is, I think, too
hard:
CRE
38 matches
Mail list logo
