Re: lastval exposes information that currval does not - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: lastval exposes information that currval does not
Date
Msg-id 20060728205818.GD3035@svana.org
Whole thread Raw
In response to Re: lastval exposes information that currval does not  (Phil Frost <indigo@bitglue.com>)
List pgsql-hackers
On Fri, Jul 28, 2006 at 04:42:11PM -0400, Phil Frost wrote:
> Again, fix is really simple. Document the issue, making it damn clear in
> the docs that the schema usage check means *nothing* when accessing an
> object by OID, and advising users that the ways to access things by OID
> are obscure but present and changing, so relying on the schema usage
> privilege is not a good idea. I'm not asking for a 2000 line patch here.
> A simple documentation change will do -- one that doesn't try to skirt
> around the issue like a dirty little secret.

Well, I suppose you could add something like the following:

If you use use low-level functions like relation_open/index_open/etc no
permission checks are done at all. No schema check, nothing. There is
also no check for possible deadlock issues, no check whether you got a
strong enough lock for the operation you are trying to do. Caveat
emptor. If you want to be sure you are not bypassing security checks,
use the SPI interface.

Would that help? You're talking about the schema check as if it's a
special case, but when people use low-level functions they have to
check *everything* themselves.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: SubPostmasterMain startup should be a critical section?
Next
From: "Marko Kreen"
Date:
Subject: Re: [PATCHES] [PATCH] Provide 8-byte transaction IDs to user level