At 11:41 AM 15/08/2004 +0200, you wrote:

>These are the steps I have just carried on a third Linux system which has
>never had Firebird on it:
>1. Download this RPM: FirebirdSS-1.5.1.4481-0.i686.rpm;
>2. Install as root;
>3. Check there are no environment variables beginning with ISC_ or containing
>SYSDBA;
>3. As a local user (i.e. not root, and with no Firebird relevant environment
>variables set...) issue:
> /opt/firebird/bin/isql /opt/firebird/examples/employee.fdb
>
>I can then access the database, update data, create tables, and
>SELECT user FROM RDB$DATABASE gives me the name of the current Linux user.
>I can also open security.fdb and view all entries in the table users. I
>cannot
>drop any database objects though.
>
>/opt/firebird/bin/isql localhost:/opt/firebird/examples/employee.fdb
>has the same result;
> /opt/firebird/bin/isql server:/opt/firebird/examples/employee.fdb
>(where server resolves the machine's external IP) requires a valid database
>login.

Aaah, OK, you are talking about system users here, not database
users. And, yes, on POSIX platforms Firebird accepts system users "as-is"
and bypasses server authentication. Any users with root privileges logging
in via localhost will be just like another SYSDBA user.

>By changing the "RemoteBindAddress" parameter in firebird.conf to the
>external
>IP only I can "work round" and force authentication.

Correct.

>On the other hand (flash of inspiration), when I download and install the
>Classic version (FirebirdCS-1.5.1.4481-0.i686.rpm) , things work as expected
>- I can only log in with a valid user account, at this point SYSDBA.
>
>Is there some difference between the Super and Classic security models? Or
>possibly a problem with the Superserver RPM?

Between the security models, no, there's not meant to be. There is a
difference in the access model, though. Unlike Superserver, Classic
permits direct connection to the database file for a local user. By
default, the RPM installs this direct-connectable client which (I *think*)
allows access to root and any users with root privs but not to any users
who don't have filesystem privs to the database file. If you use
localhost, Classic doesn't distinguish it from truly remote connections and
requires server-level authentication.

Note that wherever a system user logs in with a database username and
password, its system privileges aren't considered.

> > However, there's one nasty: any user with a valid login can CREATE (and
> > thus OWN) a database, or create (and thus own) new objects in an existing
> > database. In v.1.5 and on, you can help to make it harder by using path
> > aliasing and also restricting the locations where the server is allowed to
> > read or write database files (DatabaseAccess in firebird.conf).
>
>Do you mean valid Firebird login?

Yes.

>Sorry to keep bugging you on this.

It's as well you did. The guy who builds the Superserver and is also
reviewing the security model for Firebird 2 is Alex Peshkov. Alex doesn't
watch this list. Can you re-post a "fresh" version of your posting (the
one I'm answering now), NOT a forward, to the firebird-devel list. Be sure
you mention the build numbers.

Now, in your posting you don't say what kind of privs these non-root users
have. It's my understanding that system users without root privs *can't*
access database objects. If you're observing that they can then something
is amiss, at least according to my understanding. I mostly use Classic and
I've got some reinstalling to do on my superserver machine before I can
check out your observations.

When you repost to devel, be as clear as you can about the details.

/heLen