Extend DPB / Connection String to specify database being it's own security one
(self-security database)
-------------------------------------------------------------------------------------------------------
Key: CORE-5186
URL: http://tracker.firebirdsql.org/browse/CORE-5186
Project: Firebird Core
Issue Type: Improvement
Affects Versions: 3.0 RC2
Reporter: Arioch
In "wild world" use of FB 2.x there are repetitive patterns where central
security database becomes unavailable.
Occasional FB de-installation, database move to another server, installation of
another bundled software that removes silently FB and installs its own version,
etc.
It is not always that FB-using application has a dedicated server and dedicated
administrator. Being low-footprint and low-maintenance was always a feature of
IB/FB family.
Also for some workloads it would be great to give regular users ability to
create/fork databases, without giving them root/admin grants over the server
machine itself to edit database.conf
Security considerations:
1. If the database file contains authentication data - then it is designed to
be self-secured and no security hole is added.
2. Different auth-plugins might have different auth-data and the database can
bear two auth-data sets, for two different plugins (say, after migration from
one plugin to another). This can be hardened by
2.1. Extending RDB$DATABASE to specify the only allowed, selected auth-plugin,
or
2.2. Providing a command to purge from the acting security database any
auth-data for a specified plugin ("revoking" auth-rights from that plugin for a
specified db) and then enumerating through all available auth-pugins that would
try to recognize application-given credentials and find ther auth-data in the
self-secured DB.
3. Some plugins may have no auth-data inside the database, exclusively relying
on external authentication (like OS-level Trusted Auth).
3.1. If it would be decided to only have one plugin per self-secured DB and to
extend RDB$Database, then that poses no security risk
3.2. If it would be decided to allow several auth-plugins simultaneously work
with a self-secured DB then only Trusted Authentication plugin should be
allowed to work without having explicit auth-data in the target database. Other
auth-plugins that do not mandatory leave footprints in the security database
should be demanded to refuse to operate in self-security mode.
It would also be nice if a standard name for Connection String parameter be
documented for this feature, so different connection libraries ( ADO, ODBC,
JDBC, Python, Delphi, etc ) - thus different developers and application users -
would more or less uniformly specify this feature when parsing given settings
into DPB array.
PS. This ticket is essentially a scaled-down version of over-bloated
http://tracker.firebirdsql.org/browse/CORE-4641
More rationale and discussion can be found there.
Since this ticket has more narrow focus and less security implication i vote to
close CORE-4641 (won't do or invalid) and let it remain in archive for
reference purposes only.
PPS. I hope that there would be 3.0.x or 3.x build that can implement this
relatively isolated feature, as waiting two more years for 4.0 just to recover
a minor connection-level feature from 2.x seems a bit long.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
