tada
Is it possible to install pljava without superuser role?
I am trying to build and install 1.6.2 with PG13 on ubuntu 21.04.
when the user had superuser role, the installation was successful.
When trying to install without superuser role, I got the following error:
2021-08-11 04:52:21.309 EDT [6838] admin@admin LOG: statement: create extension pljava;
2021-08-11 04:52:21.884 EDT [6838] admin@admin ERROR: java.sql.SQLException: An attempt was made to call a PostgreSQL backend function after an elog(ERROR) had been issued
I have already added 'trusted = true' in pljava.control.
trusted = true is a feature new in PostgreSQL 13, and so far, PL/Java has not been implemented or tested to support being installed that way.
It might not be difficult, but this would have to be considered an enhancement request.
@jcflack Thanks! Shall I open another ticket here or elsewhere? Or can I mark this issue as 'enhancement request'?
The proximate issue here is that PL/Java accomplishes most of its installation by executing its own autogenerated deployment descriptor, and DDRExecutor.Plain.execute includes an executeAsOuterUser, which is correct for the usual case where a jar is being deployed from sqlj.install_jar, which is a SECURITY DEFINER function, and the commands in the jar should be executed as the outer user who has called install_jar.
In this setting, however, its effect is to drop the effective superuser identity imposed by CREATE EXTENSION when the extension is marked trusted.
It would be a simple matter of programming to detect the trusted-extension case and handle it differently.
A larger task would be to go carefully through the PostgreSQL Security Considerations for Extension Scripts and make sure that everything PL/Java is doing at installation time is as compliant as possible. That would be a worthwhile review in any case, but especially important before approving a trusted mark in the control file, as that expands the threats beyond Trojan-horsing a superuser to include privilege escalation by a non-superuser.
For example, CREATE OR REPLACE is currently used in many places for convenience; more complicated logic would be needed to address the concerns, such as a maliciously prepopulated schema, suggested in the Security Considerations. It might be easy to support initial installations (when recognizeSchema returns EMPTY), but more work before updates could be supported as confidently.