Thread: Procedural language permissions and consequences
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
Peter Eisentraut <peter_e@gmx.net> writes: > 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? Just that I imagine it's quite useful, while hacking on a procedural language, to be able to restart the postmaster and reload the library, rather than relinking and reinstalling the postmaster binary. So keeping the option for PLs in shared libraries is probably a good idea, though having the "standard" ones compiled in makes some sense. Wouldn't a postmaster statically linked with libperl.a and libpyhon.a be pretty big? Would that cause problems? -Doug -- Let us cross over the river, and rest under the shade of the trees. --T. J. Jackson, 1863
Peter Eisentraut <peter_e@gmx.net> writes:
> 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?
The arguments against this seem pretty thin on review. I would like to
be able to remove a language I don't want --- but I have no objection
to reversing the default.
> 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.
This I do *not* like. plpgsql is the single thing keeping us honest
on portability of shlib extensions. If the default and only tested
behavior is for statically-linked PL extensions, you can be sure that
dynamically-linked extensions will be suffering bit rot very soon.
And I do not see it as our problem that perl and python make life
unnecessarily difficult for those who would include them as libraries.
Tcl showed the way years ago; it's past time for those guys to see the
light, if they'd like to be adopted more widely.
See also Doug's points, nearby.
regards, tom lane
Tom Lane writes: > This I do *not* like. plpgsql is the single thing keeping us honest > on portability of shlib extensions. That is not correct. The regression tests load and use all kinds of other shared library extensions. I certainly don't like the notion you suggest that we should create or keep arbitrary detours in the common usage path just to prove that those detours still work. That is what test suites are for, and I'd be happy to provide more tests if what we currently have doesn't satisfy you (including a dummy dynamically loaded language handler?). I could see a build-time option to determine in which way the PL handlers are linked, but I really don't buy this argument. > And I do not see it as our problem that perl and python make life > unnecessarily difficult for those who would include them as libraries. In a sense it is our problem, because we are providing features that are based on interfaces that don't officially exist, and we are making life more difficult for users that way. Years of Apache/mod_perl didn't convince anybody to provide a shared libperl, so what makes you think someone is going to start on our say-so? -- Peter Eisentraut peter_e@gmx.net
Doug McNaught writes: > Just that I imagine it's quite useful, while hacking on a procedural > language, to be able to restart the postmaster and reload the library, > rather than relinking and reinstalling the postmaster binary. So > keeping the option for PLs in shared libraries is probably a good > idea, though having the "standard" ones compiled in makes some sense. PLs work just like user-defined C functions, so the possibility to load your own is not going anywhere. > Wouldn't a postmaster statically linked with libperl.a and libpyhon.a > be pretty big? Would that cause problems? I wouldn't think so. First, if you link statically you only get the code you actually use (more or less). Second, even if you get most of it, code is only loaded into memory if you actually use it. Third, if you don't like it you should provide the appropriate shared libraries and the linker should use them automatically. -- Peter Eisentraut peter_e@gmx.net
Re: Procedural language permissions and consequences
From
"Adrian 'Dagurashibanipal' von Bidder"
Date:
[Hi all! Time for an introduction: I'm just a postgresql user with an interest for the theory behind it (cs student), so I've started to read hackers a while back. As the most frequent reason for me being annoyed about Linux is the Packaging system I just wanted to throw this in here:] On Wed, 2002-01-16 at 04:09, Peter Eisentraut wrote: > 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. A reason against this not addressed by the others: Doing the languages as shared libraries opened only at runtime enables for more easy packaging - psotgresql core pkg with optional psql-tcl, psql-perl,... packages. Linking the libraries in requires packagers to do postgresql, postgresql-perl, postgresql-tcl, postgresql-perl+tcl etc. packages. (I don't know exactly if packagers currently use this possibility. It's been a while since I last installed postgres) Greets -- vbi