Added to TODO:
> * Tighten trigger permission checks
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php
and:
> * Tighten function permission checks
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00568.php
>
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Is this true for on-select rules too? In that case, couldn't any
> user run his code as postmaster by creating an appropriate on-select
> rule and waiting until somebody/cron backups the database using pg_dump?
I don't see any issue for views' on-se
Tom Lane wrote:
Martijn van Oosterhout writes:
The trigger never runs as the owner of the table AIUI, only ever as the
definer of the function or as session user.
Yeah. This might itself be seen as a bug: I think you could make a
reasonable case that the default behavior ought to be to run a
Martijn van Oosterhout writes:
> The trigger never runs as the owner of the table AIUI, only ever as the
> definer of the function or as session user.
Yeah. This might itself be seen as a bug: I think you could make a
reasonable case that the default behavior ought to be to run as the
table owne
Martijn van Oosterhout wrote:
On Fri, Dec 15, 2006 at 11:52:33AM -0500, Andrew Dunstan wrote:
Isn't the problem that they can do more than just things with the table?
If the trigger runs as the owner of the table it can do *anything* the
owner can do. So if we allow the alter privilege to in
On Fri, Dec 15, 2006 at 11:52:33AM -0500, Andrew Dunstan wrote:
> Isn't the problem that they can do more than just things with the table?
> If the trigger runs as the owner of the table it can do *anything* the
> owner can do. So if we allow the alter privilege to include ability to
> place a t
Albe Laurenz wrote:
Looking at pg_trigger I have the impression that there is no such thing
as an 'owner of a trigger', and consequently the owner of the trigger
would automatically be the table owner.
I understand the reservations about the TRIGGER privilege, but I think
that it is obvious anyw
Peter Eisentraut wrote:
> Tom Lane wrote:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
The question in my mind is what privilege to check and when.
>>>
>>> By extrapolation of the SQL standard, I'd say we'd need to check
>>> the EXECUTE privilege of the function at run t
Josh Berkus writes:
>> ... we'd need to check the EXECUTE
>> privilege of the owner of the trigger. The trick is figuring out who
>> the owner is. If it's the owner of the table, then TRIGGER privilege
>> is effectively total control over the owner of the table.
> If that's the case, then a sep
Peter,
> PostgreSQL only allows a trigger action of "call this function", so in
> the SQL standard context that would mean we'd need to check the EXECUTE
> privilege of the owner of the trigger. The trick is figuring out who
> the owner is. If it's the owner of the table, then TRIGGER privilege
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The question in my mind is what privilege to check and when.
> >
> > By extrapolation of the SQL standard, I'd say we'd need to check
> > the EXECUTE privilege of the function at run time.
>
> Certainly EXECUTE
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The question in my mind is what privilege to check and when.
> By extrapolation of the SQL standard, I'd say we'd need to check the
> EXECUTE privilege of the function at run time.
Certainly EXECUTE privilege is what to check, but
Tom Lane wrote:
> The question in my mind is what privilege to check and when.
By extrapolation of the SQL standard, I'd say we'd need to check the
EXECUTE privilege of the function at run time.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of bro
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Permissions on a trigger function seem not to be checked,
> and I can execute a function for which I have no privileges.
Only if it's a trigger function, but I agree this is not very good.
The question in my mind is what privilege to check and when.
I
14 matches
Mail list logo
