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

On Sun, Jul 09, 2006 at 11:24:38AM -0400, Phil Frost wrote:
> On UNIX it is also clearly defined that if one does not have execute
> permissions on a directory, one can not open files within it by *any*
> *means*. There are no procedures that bypass this by taking an inode
> number directly.

Well, not entirely true. If a file exists in multiple directories, you
can open it as long as any of the directories are currently accessable
to you (which is not the same as being accessable if you logged in
again).

However, the issue has been confused here by two completely different
examples. In one case you prepare a statement and then execute it later
which succeeds even though if you reprepared the statement it would
fail. This is no different from the UNIX case where having an open file
survives removing of permissions and even deletion.

> It is generally understood in the UNIX commuinity that adding a function
> in a new version that grants capabilities that were previously
> unavailable is an obvious security bug.

In this case you're referring to the lastval() issue. That case is
debatable I guess... You're suggesting it return a permission error
instead.

It's a little odd, though it think it's defensible position though. IMO
you should simply drop the lastval() function altogether, since I don't
think it's really that useful in exchange for the problems it creates.

> If it doesn't make sense to be able to revoke permissions on objects
> already accessed, why is this the behaviour of everything except the
> schema usage check? Does your definition of "already accessed" include
> "accessed in a 'security definer' procedure intended to prevent the
> caller from accessing an object directly"?

Well, that's a good question. At a guess it's because the
select/update/delete permissions are a property of the table, whereas
the schema is not. The table is a member of the schema. All that
suggests is that you should be revoking the permissions on the table
itself, rather than on the schema.

In the same vein, when reloading the pg_hba.conf, the database doesn't
immediatly disconnect all users who would be disallowed by the new
rules.

> Given that there are already several ways to bypass the check for usage
> on a schema, and the developers seem to not be bothered at all by adding
> more, of what security use is the schema usage privilege?

Several other ways? If there were a case where a user who has never had
access to a schema could access something in it, that would be an
issue. But arguing about when a revoke should take effect is a
completely different issue.

IME the developers are extremely interested in security issues.

> At a minimum, I'd like to see the documentation updated to document the
> weakness of the usage privilege, and how to prevent these exploits. I'll
> write the patch if there is agreement. Ideally, I'd like to see the
> usage privilege changed to something more consistent and useful.

I think it might be helpful for the documentation to state that USAGE
controls whether people can lookup objects within a schema and that
removing USAGE doesn't block access to the objects themselves, only
that they may not be referred to by name. To do that you need to revoke
permissions on the objects themselves.

I'm not a core developer though, so my opinions aren't really that
relevent. Do other database systems work the way you expect?

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.