Re: lastval exposes information that currval does not

Docs updated:

<para>
For schemas, allows the grantee to find objects contained in the
specified schema (assuming that the objects' own privilege requirements
are also met).
</para>

---------------------------------------------------------------------------

Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> 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(at)svana(dot)org> http://svana.org/kleptog/
> > From each according to his ability. To each according to his ability to litigate.
-- End of PGP section, PGP failed!

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +