Peter Morris wrote:

>
> Let's start a petition :-)
> I would love it too !
>

Rather than petition, you might want to polish your coding
skills, or at least come up with a detailed, meaningful
definition of the requirements and existing problems.

The priorities for firebird are strongly influenced by what
people are actually willing to DO. (the linux-kernel mailing
list has a 'show us the code' rule. You're not encouraged to
discuss new features etc. unless someone already has a patch
which demonstrates the idea in question. This keeps the
discussion to things that might actually happen. The point
being that we can spend all of our time discussing good
ideas, but if no one is going to implement them, it just
amounts to software engineering masturbation.)

IMHO, there are currently so many problems with having
untrusted access to FB that I would strongly discourage
(web hosting) ISPs from offering it as part of their
hosting environment.
(the only possible exception would be alex's suggestion)
This is independent of exposing 3050 over the internet (which
is, IMHO, far too dangerous to consider.) The situation
is that the ISPs clients don't trust each other, and
the ISP doesn't trust it's clients.

To make firebird acceptable for this kind of use would
require a complete examination (and significant rework) of both
the DB level and OS level authentication and access control
systems. These systems are currently haphazard, poorly designed
(if designed at all), and have so many corner cases that it is
difficult to fully understand them.
(an alternative would be to create a version of FB which
is completely embeddable, allowing each user to run their
own complete copy without any interaction with each other
or elevated privileges. This is an idea I've been tossing
around in my head for a while, and will try to post on
in the future.)

I personally would be strongly opposed to an approach which
consisted patching up the most obvious problems without any
overall vision.

A good first step in this direction would be a detailed
(design) discussion of how these things should work.

Some points to consider:
1) shortcomings in database level permission.
For example the metadata issues mentioned in this
thread.
2) current mess of user authentication (OS level on
unix, isc4.gdb, interactions between them.)
3) need for server level controls. Currently any authenticated
user can create and connect to databases, UDFs, external
tables)
4) security risks in the code, such as unsafe string operations,
what operations are done with elevated (e.g. root or
localsystem) privileges.

The above is NOT a comprehensive list, just some things off the top
of my head.

--
Reed Mideke
email: rfm(at)cruzers.com -If that fails: rfm(at)portalofevil.com