On Apr 22, 2006, at 1:13 PM, Florian G. Pflug wrote:
Why don't you just use "SET SESSION AUTHORIZATION somerole", and then
scan
the to-be-executel sql scripts for any occurence of "reset session
authorization",
and ignore the script it matches.
Of course you'd need to be a bit carefull to c
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Why don't you just use "SET SESSION AUTHORIZATION somerole", and then scan
the to-be-executel sql scripts for any occurence of "reset session
authorization",
and ignore the script it matches.
What would probably be better is a wa
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Why don't you just use "SET SESSION AUTHORIZATION somerole", and then scan
> the to-be-executel sql scripts for any occurence of "reset session
> authorization",
> and ignore the script it matches.
What would probably be better is a way to do SET S
Agent M wrote:
Sorry, but you misunderstand- nowhere am I interested in the role's
password. My previous suggestion was to add a password to set session
authorization itself so that if the authorization were to be reset, it
would need to be done with that password; the password itself could be
Sorry, but you misunderstand- nowhere am I interested in the role's
password. My previous suggestion was to add a password to set session
authorization itself so that if the authorization were to be reset, it
would need to be done with that password; the password itself could be
machine-generat
Agent M <[EMAIL PROTECTED]> writes:
> I really haven't provided enough details- my fault. What I want to
> accomplish is a general-purpose timer facility for postgresql.
I'm not really sure why you think it'd be a good idea for such a thing
to operate as an unprivileged user that gets around its
I really haven't provided enough details- my fault. What I want to
accomplish is a general-purpose timer facility for postgresql. Ideally,
arbitrary roles provide statements to run at certain intervals. The
benefit here is that the user connections can go away and only a single
timer connection
"A.M." <[EMAIL PROTECTED]> writes:
> On Thu, April 20, 2006 4:21 pm, Tom Lane wrote:
>> I think the correct way to do what you want is via a SECURITY DEFINER
>> function.
> Perhaps I can't wrap my head around it- I have the SQL as a string in a
> table.
Well, the simplest thing would be
On Thu, April 20, 2006 4:21 pm, Tom Lane wrote:
> "A.M." <[EMAIL PROTECTED]> writes:
>
>> It seems I am stuck so please allow me to propose an extension:
>> SET SESSION AUTHORIZATION user [WITH PASSWORD 'password];
>>
>
> This idea is extremely unlikely to be accepted, as the password would be
> at
On Thu, Apr 20, 2006 at 04:06:19PM -0400, A.M. wrote:
> The problem is that I wish to run arbitrary SQL as an unprivileged user
Would wrapping the SQL in a stored procedure with "security
definer" help any ?
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9
"A.M." <[EMAIL PROTECTED]> writes:
> It seems I am stuck so please allow me to propose an extension:
> SET SESSION AUTHORIZATION user [WITH PASSWORD 'password];
This idea is extremely unlikely to be accepted, as the password would be
at risk of exposure in places like the pg_stat_activity view.
I
Hello,
I have written a crontab-like daemon which accepts jobs from users through
a table and executes SQL statements after certain events or intervals.
This daemon maintains a persistent connection to the database as a
superuser.
The problem is that I wish to run arbitrary SQL as an unprivileged
12 matches
Mail list logo
