Procedural language permissions and consequences
От | Peter Eisentraut |
---|---|
Тема | Procedural language permissions and consequences |
Дата | |
Msg-id | Pine.LNX.4.30.0201152047380.733-100000@peter.localdomain обсуждение исходный текст |
Ответы |
Re: Procedural language permissions and consequences
Re: Procedural language permissions and consequences |
Список | pgsql-hackers |
For the next release, I'd like to implement permissions for procedural languages. It would be one permission called USAGE, which allows the user to create a function using that language. I will reuse the aclitem[] approach, in the same way as I'm already doing for functions. The first consequence is that we could get rid of createlang as the primary means of access control to languages. I would like to install all languages by default (excluding only those that haven't been included by "configure"). Would people be afraid if we made the trusted languages available to all users by default? That would really be a lot more convenient. The "trusted" flag could be done away with. However, the current untrusted languages (pltclu and plperlu) actually use the trusted flag both as an external access control and internally to decide how to behave. We could keep the latter use for now, until perhaps someone invents a generic language configuration mechanism. Furthermore, we can conveniently eliminate the problems related to finding all the language handlers as shared libraries. Since all languages are installed by default we can just link the handlers right into the postmaster, for which we don't need shared libraries. That should give a great boost to languages that are currently hard to build, i.e., PL/Perl and PL/Python. And the build system would become a lot simpler and more portable. Any comments on these points? -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: