Perhaps udf's need some form of code signing (storing the certs in system
tables) to ensure that the udf in effect is the one that was originally
installed and came from a trusted (or at least identified) source.

----- Original Message -----
From: "Helen Borrie" <helebor@...>
To: <IB-Architect@egroups.com>
Sent: Saturday, December 02, 2000 9:50 PM
Subject: Re: [IB-Architect] UDF and null


At 11:39 AM 02-12-00 +0100, you wrote:
> >Perhaps the security problem has more to do with the fact that currently
> >only the declaration is compiled in the database (compiled? maybe just
> >"stored"..). So a malevolent person could write a trojan horse
ib_udf.dll
> >or ib_udf.so with bona fide functions replaced by malicious ones with
> >identical name and parameters, make it available as a bin download and
> >catch a lot of eager SYSDBAs with their pants down.
>
>Udfs are stored into the dbf in system tables, we can by default allow
>SYSDBA to add user defined functions to database by changing the privileges
>to RDB$FUNCTIONS and RDB$FUNCTION_ARGUMENTS.
>I think If a user can't declare a user defined function, and the defined
>functions are well programmed and stable there is no security hole.

Only the declarations of the UDFs are stored in the system tables.
The UDFs themselves are completely external to the database. As things
stand now, as long as the UDF exists in the library as declared and the
declaration is correct, the database doesn't know nor care what the
function does.

>I think the best way is to allow the descriptor type, it's backguard
>compatible and transparent to old udfs.

I like the *idea* of the descriptor and I think it would be easier to
debug. But as long as the execution is external, it is vulnerable to
external interference.

Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com