On 13/12/2021 07:14, Alex Peshkoff via Firebird-devel wrote: >> The problem is that if it's available in the server, it can be declared >> in all databases. > > But since v.3 we have control on access to UDR. I suppose DS meant > something like this: > > # ./isql -user guest employee > Database: employee, User: GUEST > SQL> select sum_args(1,2,3) from rdb$database; > Statement failed, SQLSTATE = 28000 > no permission for EXECUTE access to FUNCTION SUM_ARGS > SQL> >
There is server administrator, database administrators and database developers. Server administrator manages things directly in the server, has access to file system, can run processes, etc. Database administrator does not always have access to full server. And database developers create code (or declare external routines) in database. If server administrator put an UDR (or better, any external routine) library in server, it's available to all database developers. That may work for some environments, but is definitively a problem for some environments (where server administrator cannot 100% trust database developers) if the UDR can access server resources or even others Firebird databases. So some UDR may need to have its own permission system (verified by server administrator). In FB/Java that was resolved with FB/Java security database and Java sandbox security. But this Java security is deprecated in last Java release. This was good in the era of applets and application servers, but world moved on. In these days of micro services, security is managed at the container level. If we want to follow that path external routines would need to run in containers and there must be a cloop proxy for out-of-process calls of our interfaces methods going to the Firebird server. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
