Обсуждение: 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

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

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

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 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



--
KaiGai Kohei <kaigai@kaigai.gr.jp>

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