Thread

  1. ALTER .. OWNER TO error mislabels schema as other object type

    Robert Haas <robertmhaas@gmail.com> — 2012-12-20T16:38:03Z

    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
    
    
    
  2. Re: ALTER .. OWNER TO error mislabels schema as other object type

    Tom Lane <tgl@sss.pgh.pa.us> — 2012-12-20T16:46:32Z

    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
    
    
    
  3. Re: ALTER .. OWNER TO error mislabels schema as other object type

    Robert Haas <robertmhaas@gmail.com> — 2012-12-20T17:19:12Z

    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
    
    
    
  4. Re: ALTER .. OWNER TO error mislabels schema as other object type

    Kohei KaiGai <kaigai@kaigai.gr.jp> — 2013-01-02T15:35:31Z

    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>
    
  5. Re: ALTER .. OWNER TO error mislabels schema as other object type

    Robert Haas <robertmhaas@gmail.com> — 2013-01-07T16:57:27Z

    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