From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Oliver Elphick <olly(at)lfix(dot)co(dot)uk> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Schema (namespace) privilege details |
Date: | 2002-04-19 01:24:18 |
Message-ID: | 3CBF71C2.4000903@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Oliver Elphick wrote:
> On Fri, 2002-04-19 at 00:14, Tom Lane wrote:
> I think it could be both: a database owner may not want any schemas
> created by anyone else, or by some particular user; alternatively, the
> administrator may not want a particular user to create any schemas
> anywhere. These are two different kinds of restriction:
>
> GRANT CREATE SCHEMA TO user | PUBLIC
> REVOKE CREATE SCHEMA FROM user | PUBLIC
>
> would allow/disallow the user (other than the database owner) the
> theoretical right to create a schema, whereas
>
> GRANT CREATE SCHEMA IN database TO user | PUBLIC
> REVOKE CREATE SCHEMA IN database FROM user | PUBLIC
>
> would allow/disallow him it on a particular database. Having both gives
> more flexibility and allows different people control for different
> purposes (suppose someone needs to pay for the privilege to create
> schemas in a variable set of databases; the general permission could be
> turned on or off according to whether the bill was paid.). A general
> permission would be needed before permission could be effective on a
> particular database.
I like this general idea and syntax. But it seems awkward to have to
have the privilege granted twice. What about:
GRANT CREATE SCHEMA [IN { database | ALL }] TO user | PUBLIC
REVOKE CREATE SCHEMA [IN { database | ALL }] FROM user | PUBLIC
where lack of the IN clause implies the current database, and ALL
implies a system-wide grant/revoke. System-wide could only be issued by
a superuser, while a specific database command could be issued by the DB
owner or a superuser.
>
>>Should the owner of a database (assume he's not a superuser) have the
>>right to drop any schema in his database, even if he doesn't own it?
>>I can see arguments either way on that one.
>
>
> I think a database owner should be able to override the owner of a
> schema within the database; similarly a schema owner should be able to
> override the owner of an object within the schema. This makes sense in
> practice, since the higher owner can delete the schema/object and
> recreate it under his own ownership; so there is little point in not
> allowing him to change it directly.
Yeah, I still feel that the owner of a "container" object like a
database or schema should have complete control of whatever is contained
therein. Anything else would strike me as surprising behavior.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2002-04-19 01:49:12 | Re: Schema (namespace) privilege details |
Previous Message | Tom Lane | 2002-04-19 01:19:29 | Re: Schema (namespace) privilege details |