Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();
Дата
Msg-id CAFj8pRC8crCE7Bgf=x6ic859FkNYH1YkCtpURMDyNoRxqHFtkw@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();  (Joel Jacobson <joel@trustly.com>)
Ответы Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();  (Joel Jacobson <joel@trustly.com>)
Список pgsql-hackers


2017-02-22 8:06 GMT+01:00 Joel Jacobson <joel@trustly.com>:
Hi Hackers,

Currently, it's only possible to grant/revoke execute on functions to roles.

I think it would be useful in many situations, both for documentation purposes,
but also for increased security, to in a precise way control what
other function(s)
are allowed to execute a specific function. 

This would be useful for functions that are not supposed to be used
manually by any human or any other function(s) than the few places
where the function makes sense to use.

Thoughts?

I had similar idea. The possibility to specify a list of functions can have a performance impact when ACL can be too long.

Just idea - what is based on idea "using schema like package". We can introduce new kind of functions X, that cannot be executed on toplevel - and can be executed only from standard functions defined in same schema.

Usage of X functions can be locked in schema.

It allow similar functionality to your proposal, but the check can be faster - and you don't need to maintain list of enabled caller functions.

Regards

Pavel


/Joel


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Replication vs. float timestamps is a disaster
Следующее
От: Joel Jacobson
Дата:
Сообщение: Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();