Subject | RE: [ib-support] Database security (clarification for alan?) |
---|---|
Author | unordained |
Post date | 2003-04-30T08:50:07Z |
---------- Original Message -----------
From: "Alan McDonald" <alan@...>
To: <ib-support@yahoogroups.com>
Sent: Wed, 30 Apr 2003 09:21:46 +1000
Subject: RE: [ib-support] Database security
[snip]
--------------------------------------------------------------------------------
the point was this:
data in a firebird database file is always vulnerable if:
- the .gdb file can be accessed by a firebird server somewhere, and
- someone else has access to the sysdba password on that firebird server
ergo, to protect your data from being stolen/corrupted, you have to solve one problem or the other.
to solve the first, you can put the file somewhere "safe" from any but one database server
instance, whose sysdba password you (and you alone) control. to solve the second one instead, just
make sure nobody gets the sysdba password who doesn't need it.
you seemed to ask why i was relating this to hosting companies (like geocities) --
in the case of, say, a large hosting company who wanted to have lots of little firebird databases
(for each hosted user, for example)
- either they don't give out the sysdba password to any users (preferable)
- they give each user their own instance of firebird, running on a different port (so bind()
doesn't fail) and each instance has its own sysdba password. each instance also runs only with the
permissions of that user -- so it can't go looking in other home directories for databases.
however, i believe i remember that firebird, even without the sysdba password, would at least let
you look at the metadata of a database file to which it has access. for a lot of hosting companies,
that's bad -- if they run just one instance of firebird for all of their users (not giving out the
sysdba password) those users can still look at the metadata for each others' database files. (the
database server winds up running as -some- user, root or not, that has at least read access to all
the individual database files.) while it's not always completely catastrophic that someone might
get a glance at your metadata ... it doesn't do much to help administrators feel firebird is a good
choice for hosting sites of this sort. (Geocities, multimania, lycos, homestead, what-have-you.)
has this been fixed?
users are per-instance, not per-file. this also means, for large hosting companies, that they can't
let their users determine their own user names on the database files they create -- there might be
conflicts with other users on the system who wanted the same usernames for -their- database
file ... and i know that for running code for a web-app, i'd much rather have multiple user names
than just one all-powerful username given to me by the site administrators, to use on all my
database files ... it just wouldn't be safe for, say, php code to be running with full metadata
control over the database files, if it's not necessary.
was i less vague this time?
and yes, no matter where the file is, root can always get to it -somehow-. there's no helping that.
at least with sysdba, it's limited to places the server instance can reach ... which may not be the
entire file system.
-philip
From: "Alan McDonald" <alan@...>
To: <ib-support@yahoogroups.com>
Sent: Wed, 30 Apr 2003 09:21:46 +1000
Subject: RE: [ib-support] Database security
[snip]
> Not sure what you mean here... I can put a MySQL database on another server[snip]
> and open it with root. I can also open all databases on my MySQL server with
> my root login.
>
> Alan
--------------------------------------------------------------------------------
the point was this:
data in a firebird database file is always vulnerable if:
- the .gdb file can be accessed by a firebird server somewhere, and
- someone else has access to the sysdba password on that firebird server
ergo, to protect your data from being stolen/corrupted, you have to solve one problem or the other.
to solve the first, you can put the file somewhere "safe" from any but one database server
instance, whose sysdba password you (and you alone) control. to solve the second one instead, just
make sure nobody gets the sysdba password who doesn't need it.
you seemed to ask why i was relating this to hosting companies (like geocities) --
in the case of, say, a large hosting company who wanted to have lots of little firebird databases
(for each hosted user, for example)
- either they don't give out the sysdba password to any users (preferable)
- they give each user their own instance of firebird, running on a different port (so bind()
doesn't fail) and each instance has its own sysdba password. each instance also runs only with the
permissions of that user -- so it can't go looking in other home directories for databases.
however, i believe i remember that firebird, even without the sysdba password, would at least let
you look at the metadata of a database file to which it has access. for a lot of hosting companies,
that's bad -- if they run just one instance of firebird for all of their users (not giving out the
sysdba password) those users can still look at the metadata for each others' database files. (the
database server winds up running as -some- user, root or not, that has at least read access to all
the individual database files.) while it's not always completely catastrophic that someone might
get a glance at your metadata ... it doesn't do much to help administrators feel firebird is a good
choice for hosting sites of this sort. (Geocities, multimania, lycos, homestead, what-have-you.)
has this been fixed?
users are per-instance, not per-file. this also means, for large hosting companies, that they can't
let their users determine their own user names on the database files they create -- there might be
conflicts with other users on the system who wanted the same usernames for -their- database
file ... and i know that for running code for a web-app, i'd much rather have multiple user names
than just one all-powerful username given to me by the site administrators, to use on all my
database files ... it just wouldn't be safe for, say, php code to be running with full metadata
control over the database files, if it's not necessary.
was i less vague this time?
and yes, no matter where the file is, root can always get to it -somehow-. there's no helping that.
at least with sysdba, it's limited to places the server instance can reach ... which may not be the
entire file system.
-philip