> > > 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
> kinda)
> > > >> 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
> stored
> > 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).
>
> Adam

I asked about another switch - they hate switches.
restore to another database doesn't tell you what's new. you'd also have to
have triggers in the security database to insert into the changes table.
It's no less a lowering in security than the other ways I suppose to have a
copy of security2.fdb lying around on the server...
adding a backup/restore cycle to the replication cycle is more overhead but
as you say - it's not all that dynamic.
The biggest problem to me, anyway, has always been synchronising the grants.
It's not much good to anyone to add a user into another server, if the role
hasn't been granted as well.
Alan