> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> I agree that you have a problem to solve, but defining the problem as
> "please can we have SET ROLE back" is not going to lead you to a secure
> solution.
Fair enough. Thanks for the analysis.
--Ian
--
Sent via pgsql-
"Turner, Ian" writes:
>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Really? What can it contain, and how are you enforcing that?
> Anything except a function call. We look for non-keyword identifier
> followed by open parenthesis, which is probably excessively
> restrictive.
I'm afraid this
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Really? What can it contain, and how are you enforcing that?
Anything except a function call. We look for non-keyword identifier followed by
open parenthesis, which is probably excessively restrictive. I'd rather have
s
"Turner, Ian" writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Exactly. If that's what you want, we can talk about it, but *SET ROLE
>> doesn't solve that problem*. In fact, a security definer function is a
>> lot closer to solving that problem than SET ROLE is. The premise of SET
>> ROL
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Exactly. If that's what you want, we can talk about it, but *SET ROLE
> doesn't solve that problem*. In fact, a security definer function is a
> lot closer to solving that problem than SET ROLE is. The premise of SET
> R
Heikki Linnakangas writes:
> Turner, Ian wrote:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>>> Actually, I don't find that to be a given. Exactly what use-cases have
>>> you got that aren't solved as well or better by calling a SECURITY DEFINER
>>> function owned by the target role?
>>
>> Oh,
Turner, Ian wrote:
>> -Original Message-
>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Actually, I don't find that to be a given. Exactly what use-cases have
>> you got that aren't solved as well or better by calling a SECURITY DEFINER
>> function owned by the target role?
>
> Oh, that
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Actually, I don't find that to be a given. Exactly what use-cases have
> you got that aren't solved as well or better by calling a SECURITY DEFINER
> function owned by the target role?
Oh, that's easy: If you want to do t
On Thu, Dec 31, 2009 at 10:36 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > We are seeking to enable SET ROLE in security-definer functions,
> since @
> > D.E Shaw there are scripts from the past that used this feature, and I
> think
> > you'd also agree that SET ROLE is security definer f
Gurjeet Singh writes:
> We are seeking to enable SET ROLE in security-definer functions, since @
> D.E Shaw there are scripts from the past that used this feature, and I think
> you'd also agree that SET ROLE is security definer functions has it's uses.
Actually, I don't find that to be a giv
Hi All,
We are seeking to enable SET ROLE in security-definer functions, since @
D.E Shaw there are scripts from the past that used this feature, and I think
you'd also agree that SET ROLE is security definer functions has it's uses.
As the code stands right now, I see that the only conce
11 matches
Mail list logo
