Thread: perm bug ?

perm bug ?

From
ivan
Date:
When ie function is whitout any grant == public have grant to execute it.
public or user who have grant to usage on this func. namepsace.

I think when i create function , the default grant should be only for
owner. specialy when function have security definer .

or , i dont know about sth like umask ???




Re: perm bug ?

From
Tom Lane
Date:
ivan <iv@psycho.pl> writes:
> I think when i create function , the default grant should be only for
> owner. specialy when function have security definer .

We did it that way to begin with, but the definition did not survive
its first beta cycle ... too inconvenient.
        regards, tom lane


Re: perm bug ?

From
"Christopher Kings-Lynne"
Date:
> We did it that way to begin with, but the definition did not survive
> its first beta cycle ... too inconvenient.

And not pre-7.3 backwards compatible...

Chris



Re: perm bug ?

From
Bruno Wolff III
Date:
On Thu, Jul 24, 2003 at 00:32:32 +0200, ivan <iv@psycho.pl> wrote:
> 
> When ie function is whitout any grant == public have grant to execute it.
> public or user who have grant to usage on this func. namepsace.
> 
> I think when i create function , the default grant should be only for
> owner. specialy when function have security definer .
> 
> or , i dont know about sth like umask ???

Note that you can create and remove public access to a function in a
transaction so that there isn't a window where unauthorized people
can use the function.


Re: perm bug ?

From
ivan
Date:
may be there could be option (while compiling) to database for many users,
like in normal public servers where everyone has own db, and option to
postgres for one database with may users (like in comrporation etc )

Defferences should be also in initdb , when pg_catalog is created

and sth like default grant in runtime settings
??
On Wed, 23 Jul 2003, Tom Lane wrote:

> ivan <iv@psycho.pl> writes:
> > I think when i create function , the default grant should be only for
> > owner. specialy when function have security definer .
>
> We did it that way to begin with, but the definition did not survive
> its first beta cycle ... too inconvenient.
>
>             regards, tom lane
>