Subject Re: Synchronize security2.fdb
Author Adam
--- In, "Alan McDonald" <alan@...> wrote:
> > Alan McDonald wrote:
> > >> One idea I had a while ago to bypass the service manager.
> > >> Create an extra table to temporary store the user/password until
> > >> replication, of course decent encrypted. After table
replication, the
> > >> password is changed by decrypting the field (via post event or
> > >> and the data is cleaned on both servers.
> > >>
> > >> HTH
> > >> Radu
> > >
> > > and this extra table is not accessible. you don't have access to the
> > > database. The service manager will not provide such access either.
> > > Alan
> >
> > The table is in the database replicated, not in the security2.fdb.
> > Now that you mentioned, one could use an additional database, just for
> > this purpose, in case of multiple database replication.
> > I know it is not the most elegant solution, but it might work...
> >
> > Radu
> the trouble I see here, is that you need to use the services manager
to add
> a user to the real security db, then a separate action (normal
connection +
> SQL) to store the same details into another database. You can't use two
> phase commit for this (SM can't be a party to 2 phase commit) so
there is a
> risk that you will have data stored in one database and not the other.
> Next there is the lowering of security , having plain text passwords
> in another database.

Hi Alan + others,

I have never had to replicate the security database, so this may or
may not work, but could you make a backup of the security database
(using the service manager), restore it as a standard database then
replicate it as required. It is surely not *that* dynamic.

I for one agree with the decision to deny all direct access to the
security database. It closes so many security attack vectors. That
said, perhaps there is a useful case that could be put to allow
replication of this information. If the decision was reversed to allow
direct connections to the database, then I would hope that it was
rather a switch in Firebird.conf to allow direct access to the
security database (off by default).