Sean Chittenden <sean@chittenden.org> writes:
> I think the attached patch addresses both of your concerns.
Perhaps something like this will work, but the patch as given can't
possibly be right (or have been tested with any care):
> + aclresult = pg_namespace_aclcheck(MyDatabaseId, GetUserId(),
> + ACL_CREATE_TEMP);
Surely that should be pg_database_aclcheck() ... and the error reporting
code just below won't be very appropriate for this case, either.
Also a comment or five would be appropriate.
A larger problem is that the reason that control makes it through that
path at the moment is this check in pg_namespace_aclcheck:
/*
* If we have been assigned this namespace as a temp namespace, assume
* we have all grantable privileges on it.
*/
if (isTempNamespace(nsp_oid))
return ACLCHECK_OK;
(Since the temp namespace is created as owned by the superuser, ordinary
users would always fail to create temp tables without this escape hatch.)
I am not at all convinced that this check could be removed, but I also
wonder whether its presence doesn't create some issues that are security
holes if we adopt your definition of how temp table creation ought to
behave.
>>> At the moment, this behavior cripples the usefulness
>>> of having a TEMP table be used as a trusted cache for data.
>>
>> What exactly do you think makes a temp table suitable as a trusted
>> cache? Or more suitable than non-temp tables?
> Revoke all privs on temp tables except from the DBA, then setup
> functions to use the temp table as a way of maintaining state
> information across transactions (within the same session).
This is pretty much a non-argument, as there is no part of it that says
that you have to revoke the right to create temp tables from Joe User.
What is necessary and sufficient is that the particular temp table you
want to keep your info in has to be owned by, and only accessible to,
the more-privileged account. You need not muck with the temp namespace
behavior before you can do that.
regards, tom lane