The new CREATE OPERATOR CLASS command will presently let you create an
index opclass if you own the datatype the class is for.  With the
recent emphasis on security I'm thinking that this is not an adequate
permission check.  We don't have any reasonable way of checking that
the provided set of operators and support functions meet the
expectations of the index AM and are mutually consistent.  This means
it's not at all difficult to make an index opclass that will crash
the backend when used.

I'm inclined to require superuser permissions to do CREATE OPERATOR
CLASS.  This would not be a loss of functionality compared to prior
releases, since the old way of creating an opclass involved manual
insertions into system catalogs, also a superuser-only thing.

Comments?

			regards, tom lane

Fri, 23 Aug 2002 15:17:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Permissions for CREATE OPERATOR CLASS
En Fri, 23 Aug 2002 15:17:25 -0400
Tom Lane <tgl@sss.pgh.pa.us> escribiï¿½:

> The new CREATE OPERATOR CLASS command will presently let you create an
> index opclass if you own the datatype the class is for.  With the
> recent emphasis on security I'm thinking that this is not an adequate
> permission check.  We don't have any reasonable way of checking that
> the provided set of operators and support functions meet the
> expectations of the index AM and are mutually consistent.  This means
> it's not at all difficult to make an index opclass that will crash
> the backend when used.

Well, maybe this reduces the usefulness of having a CREATE TYPE as
compared to being able to create operator classes as well, but I wonder
how much people create their own types and want to create operator
classes without being superusers.

Is it too difficult to check whether the functions are "good for AM"?
Does not sound like an easy task...  (halting problem maybe?)

> I'm inclined to require superuser permissions to do CREATE OPERATOR
> CLASS.  This would not be a loss of functionality compared to prior
> releases, since the old way of creating an opclass involved manual
> insertions into system catalogs, also a superuser-only thing.

If it's unsafe, users should not be able to mess with it.


I was playing around and got this:

alvh=> create type my_cash (input = cash_in, output = cash_out, internallength = variable);
ERROR:  TypeCreate: function cash_out(opaque) does not exist

-- 
Alvaro Herrera (<alvherre[a]atentus.com>)
"La fuerza no estï¿½ en los medios fï¿½sicos
sino que reside en una voluntad indomable" (Gandhi)

Fri, 23 Aug 2002 15:42:14 -0400
Alvaro Herrera <alvherre@atentus.com>
Re: Permissions for CREATE OPERATOR CLASS
Alvaro Herrera <alvherre@atentus.com> writes:
> I was playing around and got this:

> alvh=> create type my_cash (input = cash_in, output = cash_out, internallength = variable);
> ERROR:  TypeCreate: function cash_out(opaque) does not exist

Yeah, the CREATE TYPE code is now much stricter about the allowed
signatures of the I/O functions.  The input function for a type foo
must be one of
	foo_in(cstring) returns foo
	foo_in(opaque) returns foo
	foo_in(cstring) returns opaque
	foo_in(opaque) returns opaque
while the output must be one of
	foo_out(foo) returns cstring
	foo_out(opaque) returns cstring
	foo_out(foo) returns opaque
	foo_out(opaque) returns opaque
so unless you use "opaque" you cannot use the same I/O function for
two different types.  (Possibly the error message should complain about
foo_out(foo) not foo_out(opaque).)

If we hear a lot of squawks about that, we can discuss how to weaken
the rules ... but IMHO the entire point here is to introduce some type
safety into the use of I/O functions ...

			regards, tom lane

Fri, 23 Aug 2002 18:01:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Permissions for CREATE OPERATOR CLASS 