ALTER .. OWNER TO error mislabels schema as other object type
This looks busted:
rhaas=# create role clerks;
CREATE ROLE
rhaas=# create role bob in role clerks;
CREATE ROLE
rhaas=# create schema foo;
CREATE SCHEMA
rhaas=# grant usage on schema foo to bob, clerks;
GRANT
rhaas=# create aggregate
foo.sum(basetype=text,sfunc=textcat,stype=text,initcond='');
CREATE AGGREGATE
rhaas=# alter aggregate foo.sum(text) owner to bob;
ALTER AGGREGATE
rhaas=# set role bob;
SET
rhaas=> alter aggregate foo.sum(text) owner to clerks;
ERROR: permission denied for function foo
Eh? There's no function called foo. There's a schema called foo,
which seems to be the real problem: clerks needs to have CREATE on foo
in order for bob to complete the rename. But somehow the error
message is confused about what type of object it's dealing with.
[ Credit: The above example is adapted from an EDB-internal regression
test, the failure of which was what alerted me to this problem. ]
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
This looks busted:
Between this and your previous example, it's becoming clear that the
recent refactorings of the ALTER code were not ready for prime time.
Perhaps we should just revert those instead of playing bug whack-a-mole.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Dec 20, 2012 at 11:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
This looks busted:
Between this and your previous example, it's becoming clear that the
recent refactorings of the ALTER code were not ready for prime time.
Perhaps we should just revert those instead of playing bug whack-a-mole.
Well, as yet, I have no clear evidence that there is any problem with
anything other than the error messages. It seems like overkill to
revert the whole thing just for that. Not to say that there might not
be further issues, of course.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Sorry, I oversight this report.
The reason of this confusing error message is originated by incorrect
aclkind being delivered to aclcheck_error() at AlterObjectOwner_internal().
/* New owner must have CREATE privilege on namespace */
if (OidIsValid(namespaceId))
{
AclResult aclresult;
aclresult = pg_namespace_aclcheck(namespaceId, new_ownerId,
ACL_CREATE);
if (aclresult != ACLCHECK_OK)
aclcheck_error(aclresult, aclkind,
get_namespace_name(namespaceId));
}
The supplied aclkind represents the property of the object being re-owned,
not a namespace that owns the target object. So, right approach is to
give ACL_KIND_NAMESPACE being hardwired in this case, as
AlterObjectNamespace_internal() doing.
The attached patch fixes this trouble.
postgres=# create role clerks;
CREATE ROLE
postgres=# create role bob in role clerks;
CREATE ROLE
postgres=# create schema foo;
CREATE SCHEMA
postgres=# grant usage on schema foo to bob, clerks;
GRANT
postgres=# create aggregate
postgres-# foo.sum(basetype=text,sfunc=textcat,stype=text,initcond='');
CREATE AGGREGATE
postgres=# alter aggregate foo.sum(text) owner to bob;
ALTER AGGREGATE
postgres=# set role bob;
SET
postgres=> alter aggregate foo.sum(text) owner to clerks;
ERROR: permission denied for schema foo
Thanks,
2012/12/20 Robert Haas <robertmhaas@gmail.com>:
This looks busted:
rhaas=# create role clerks;
CREATE ROLE
rhaas=# create role bob in role clerks;
CREATE ROLE
rhaas=# create schema foo;
CREATE SCHEMA
rhaas=# grant usage on schema foo to bob, clerks;
GRANT
rhaas=# create aggregate
foo.sum(basetype=text,sfunc=textcat,stype=text,initcond='');
CREATE AGGREGATE
rhaas=# alter aggregate foo.sum(text) owner to bob;
ALTER AGGREGATE
rhaas=# set role bob;
SET
rhaas=> alter aggregate foo.sum(text) owner to clerks;
ERROR: permission denied for function fooEh? There's no function called foo. There's a schema called foo,
which seems to be the real problem: clerks needs to have CREATE on foo
in order for bob to complete the rename. But somehow the error
message is confused about what type of object it's dealing with.[ Credit: The above example is adapted from an EDB-internal regression
test, the failure of which was what alerted me to this problem. ]--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
Attachments:
pgsql-fix-incorrect-aclkind-on-alter-owner.patchapplication/octet-stream; name=pgsql-fix-incorrect-aclkind-on-alter-owner.patchDownload
src/backend/commands/alter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/commands/alter.c b/src/backend/commands/alter.c
index f628754..73138f9 100644
--- a/src/backend/commands/alter.c
+++ b/src/backend/commands/alter.c
@@ -632,7 +632,7 @@ AlterObjectOwner_internal(Relation rel, Oid objectId, Oid new_ownerId)
aclresult = pg_namespace_aclcheck(namespaceId, new_ownerId,
ACL_CREATE);
if (aclresult != ACLCHECK_OK)
- aclcheck_error(aclresult, aclkind,
+ aclcheck_error(aclresult, ACL_KIND_NAMESPACE,
get_namespace_name(namespaceId));
}
}
On Wed, Jan 2, 2013 at 10:35 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
The attached patch fixes this trouble.
Thanks. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers