When I first saw the external file problem I saw three issues:

1) denial of service (e.g. create /etc/nologin)
2) taking over the system (adding lines to /etc/passwd) or appending
to the registry on NT/autoexec.bat
3) copying files (even binaries copy nicely on Unix and NT using IB)

My solution is, in the IB relational system itself:

1) Map logical DB names to real DB names (protocol, server, logical
name/filename)
2) Map logical external table paths to real files and directories.
3) Map logical DB names and pathnames to user permissions in the IB
system

This abstracts all of the security and resource naming issues into the
relational model which is, in my opinion, where they belong in a
one-stop relational system like Interbase (and away for messy
configuration files which IB has avoided in the past). It allows the
sysdba and/or database owner to grant access to the relational objects
like DBs and tables. With the cooperation of the Sys Admin, most of
the security issues should go away. People will still be able to
misbehave but a clean model will minimise their scope for harm.

As I see it the parts that map logical to operating system names would
go into the the security database and the other parts would be DB
specific (and be stored in the database files).

I don't know if the Y-valve system could or should read the security
database but given IB's support for single-client/multi-DB
transactions it might be sensible for it to do so. Jim Starky wrote
that the Y-valve manages the 2 phase commits and it can be a security
issue to access two DBs in a single transaction even though it is
allowable to access them separately.

There is a lot of value in being able to place database files in
arbitrary locations (acording to the OS naming schemes and device to
file mappings). There is tremendous value in people being able to
have external tables in their home/work directories (I worked closely
with a University admin statistics/planning group: it is the sort of
facility they would have loved). It is one of the only ways to do
bulk data exports and imports in Interbase.

I have a lot more to say regarding this: I have been using a work
around for a year and a half (posted on the MERS list by
jmc@...). Borland had the problem logged as a bug - so they
knew about it and I wasn't the only person to find it. The fact that
they released v5 and v6 with such a severe known bug makes me wonder
how hard it is to fix.

Julian Cooling

PS: In private communication, Mark O'Donohue said to me, "[security
is] a dangerous thing to play with for the amateur". I agree and the
security model for Interbase needs a radical rethink. I found the bug
doing a security audit but, when I found it, I didn't bother
continuing. Has anyone completed a security audit (not of the code
but of the features)?