On Wed, Apr 20, 2011 at 12:26:01AM +0300, Peter Eisentraut wrote: > On Mon, 2011-04-18 at 19:34 -0400, Noah Misch wrote: > > On Mon, Apr 18, 2011 at 10:44:53PM +0300, Peter Eisentraut wrote: > > > On Sat, 2011-04-09 at 21:57 -0400, Noah Misch wrote: > > > > * Users can CREATE TABLE OF on a type they don't own > > > > This in turns blocks the owner's ability to alter the table/type. > > > > However, we > > > > already have this hazard with composite-type columns. A TODO to > > > > address this > > > > broadly seems in order, but it's not a 9.1 issue. > > > > > > I think we should change that to mirror the inheritance policy: you have > > > to be the owner of the "parent". Note that this is newly relevant in > > > 9.1, because you couldn't change composite types before.
I pondered this angle further. The restriction is critical for inheritance, because attaching a new child table changes query behavior for the parent. Typed tables don't have that kind of action at a distance. > > Would we add that restriction to use of "CREATE TABLE t (c comptype)" as > > well, > > or just to "CREATE TABLE t OF comptype"? > > Well, that's a tough one. It would be a regression. I would say no to > changing the former, because the fact that this prevents the type owner > from changing the type is not a regression because you couldn't change > types before at all. In 9.0, an unprivileged second party can use a composite-typed column to block "DROP TYPE". If we change nothing, 9.1 will additionally permit blocking "ALTER TYPE ALTER ATTRIBUTE", "ALTER TYPE ADD ATTRIBUTE" and "ALTER TYPE DROP ATTRIBUTE". As you say, those are all new features. Adding an ownership check to CREATE TABLE OF would remove the last two vulnerabilities; a composite-typed column does not block them, but a typed table does block them. If we add that ownership check, we'll protect some operations on the type. The cost is localized divergence from our principle that types have no usage restrictions. I'm of the opinion that it's not worth introducing that policy exception to block just some of these avenues of attack. I would not object to it, though. > Probably we need some privileges on types to address this properly. Agreed. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
