Postgres Pro
Downloads
Home   >   mailing lists

Thread: Permissions for CREATE OPERATOR CLASS

Permissions for CREATE OPERATOR CLASS

From
Tom Lane
Date:
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

Re: Permissions for CREATE OPERATOR CLASS

From
Alvaro Herrera
Date:
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)

Re: Permissions for CREATE OPERATOR CLASS

From
Tom Lane
Date:
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 offoo_in(cstring) returns foofoo_in(opaque) returns foofoo_in(cstring) returns opaquefoo_in(opaque) returns
opaque
while the output must be one offoo_out(foo) returns cstringfoo_out(opaque) returns cstringfoo_out(foo) returns
opaquefoo_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