Re: Schema (namespace) privilege details - Mailing list pgsql-hackers

From Sander Steffann
Subject Re: Schema (namespace) privilege details
Date
Msg-id 00cd01c1e731$84f58060$64c8a8c0@balefire10ww
Whole thread Raw
In response to Schema (namespace) privilege details  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Schema (namespace) privilege details  (Curt Sampson <cjs@cynic.net>)
List pgsql-hackers
Hi Tom,

> One of the things I'd like this mechanism to do is answer the request
> we've heard so often about preventing users from creating new tables.
> If the DBA revokes write access on the public namespace from a particular
> user, and doesn't create a personal schema for that user, then under this
> proposal that user would have noplace to create tables --- except TEMP
> tables in his temp schema.  Is that sufficient, or do the folks who want
> this also want a way to prevent TEMP table creation?

I can't think of a reason that temp tables should be prevented. Being able
to prevent a user from creating permanent objects is good IMHO.

> Another thing that would be needed to prevent users from creating new
> tables is to prevent them from creating schemas for themselves.  I am not
> sure how to handle that --- should the right to create schemas be treated
> as a user property (a column of pg_shadow), or should it be attached
> somehow to the database (and if the latter, how)?

Connecting this right to a database sounds like the right thing to do. (ISP
case: allow a user to do with his database whatever he wants, as long as he
stays away from other databases) But I don't know a good way to do it...

> 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 that if he owns it, he should be able to control it... Someone
owning a database should be responsible enough to manage it.

I hope these comments can help you,
Sander.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Large object security
Next
From: Damon Cokenias
Date:
Subject: Re: Large object security