Firebird Embedded vs Dienst

[Gecko]

Hallo,

ich wollte mal fragen, ob die Embedded Variante irgendwelche Nachteile (in einer Einzelplatzumgebung) gegenüber dem Dienst hat?
Ist sie z.B. merklich langsamer o.ä.?

[mkinzler]

Man kann halt nur eine Verbindung zu einer Db aufbauen und der Benutzer kann icht authentifiziert werden (keine Passwortüberprüfung). da die embedded-Library den gleichen Engine-Kern wie der Dienst besitzt, gibt es keine Unterschiede in der Performance, diese dürfte eher besser sein.

[Gecko]

Mit dem Passwortschutz ist natürlich nicht so ideal.
Würde sich also für ne MailDB weniger eignen, oder gibts da vllt. nen Workaround?

[mkinzler]

Starte doch den Server als Exe.

[Elvis]

Zitat:

Zitat von Gecko

Mit dem Passwortschutz ist natürlich nicht so ideal.
Würde sich also für ne MailDB weniger eignen, oder gibts da vllt. nen Workaround?

Wenn es mehr als einen Benutzer in der DB geben kann und der Benutzer Zugriff auf die DB-Datei bekommt, ist eine Benutzerkontrolle innerhalb der DB, sicherheitstechnisch, absoluter Blödsinn.
Es kostet dich a) nur sinnlos Performance und b) bedeutet eine vorgetäuschte, real nicht existierende, Sicherheit, dass das System unsicherer ist als ohne diese Pseudo-Kontrolle.

Wenn dein System Client/Server ist, solltest du dir von vornherein überlegen besser einen Applikationsserver zwischen die Clients und die DB zu schieben.
Der kann dann meinetwegen fbembed benutzen und als Authentifizierung kannst du dann hernehmen was immer du willst.

[Gecko]

Zitat:

Zitat von Elvis

Zitat:

Zitat von Gecko

Mit dem Passwortschutz ist natürlich nicht so ideal.
Würde sich also für ne MailDB weniger eignen, oder gibts da vllt. nen Workaround?

Wenn es mehr als einen Benutzer in der DB geben kann und der Benutzer Zugriff auf die DB-Datei bekommt, ist eine Benutzerkontrolle innerhalb der DB, sicherheitstechnisch, absoluter Blödsinn.

Ja, du hast natürlich absolout Recht.
Wie wäre die Idee, die Werte (AES) zu verschlüsseln?

Fragt sich dann natürlich, was man mit den Attatchments auf der Festplatte macht. Hier könnte man dem Benutzer ja die Wahl lassen...

[MrSpock]

Hallo Elvis,

das stimmt natürlich. Gleichzeitig kann man dem Benutzer aber den Zugriff auf die DB Datei verwähren und dann macht eine Benutzerkontrolle natürlich schon Sinn.

[Elvis]

Zitat:

Zitat von Gecko

Ja, du hast natürlich absolout Recht.
Wie wäre die Idee, die Werte (AES) zu verschlüsseln?

Ja aber mit welchem Schlüssel? Der SID des Users? Das wäre wieder unsicher wenn die Benutzer die DB-Datei sehen können.
Mit dem Password des Users? Vielleicht, aber dann könnte er es wohl nicht mehr ändern...

Wenn du es allerdings server-basiert machen würdest (was gerade bei eMail mehr als nur sinnvoll ist ;) ), wären Verschlüsselungen nach User SID und Authentifizierung wieder sinnvolle Optionen.
Ganz zu schweigen davon, dass Anwendungs-Logik, Authentifizierung und Datenspeicherung sicher auf einem Server lägen, der vor dem User physikalisch geschützt ist. (Schloß vor der Tür)
Da Authentifizierung auch mit dem von Albert vorgeschlagenen Weg nicht möglich ist[1], ist das sogar die einzig sinnvolle Architektur, die mir gerade einfällt.

Zitat:

Fragt sich dann natürlich, was man mit den Attatchments auf der Festplatte macht. Hier könnte man dem Benutzer ja die Wahl lassen...

Packe sie als Blobs mit in die DB und dann lässt sich das oben auch auf die Anhänge anwenden.

Wie du das dann wirklich umsetzt bleibt ganz bei dir, alles hier genannte ist zwangsläufig noch so abstrakt theoretisch, dass man es kaum als Hilfe bezeichnen kann. :zwinker: Eher als Richtungsweiser...

[1]Außer jeder User hätte seine eigene DB und auch nur auf diese Datei Berechtigungen. Damit hätte man praktisch einen DB-Server neuerfunden und die Zugriffskontrolle an das OS abgetreten. Nicht wirklich hübsch, IMO. ;)