Re: When and where to check for function permissions

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: When and where to check for function permissions
Date: 2002-02-13 22:34:05
Message-ID: 012e01c1b4de$8bcf42c0$8001a8c0@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thought about that. But if you have a user run through your system
and locks all the tables for a long time the least of my worries are
the permissions. Generally it's getting that damn user disconnected
then taken out back shot so that the system is moving forward again.

Anyway, the point was that if Postgresql is going to be worried about
users running stored plans on functions they don't have permission on,
then a user shouldn't expect permission to be revoked in the middle of
a transaction if they hold a lock on the item.

--
Rod Taylor

This message represents the official view of the voices in my head

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Rod Taylor" <rbt(at)zort(dot)ca>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>; "PostgreSQL Development"
<pgsql-hackers(at)postgresql(dot)org>
Sent: Wednesday, February 13, 2002 5:29 PM
Subject: Re: [HACKERS] When and where to check for function
permissions

> "Rod Taylor" <rbt(at)zort(dot)ca> writes:
> > I'd expect the revoke statement to be blocked by
> > the locks on those rows.
>
> We could do it that way, but it doesn't seem like a really good idea
to
> me --- in essence you'd be allowing a denial-of-service attack, no?
>
> regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-02-13 22:53:19 Re: [GENERAL] Postgres 7.2 - Updating rows in cursor problem
Previous Message Tom Lane 2002-02-13 22:29:50 Re: When and where to check for function permissions