In Verzeichnis schreiben mit anderen Benutzerrechten

[Delphi.Narium]

Also mal so hingedaddelt:

Die Verwaltung, was wo liegt und wer womit was machen darf kann soll muss, legst Du in die Datenbank. Da sagst Du ja, dass Du das hinbekommst.

Die Dateien kommen nicht in ein Blob in der DB, sondern in die DB wird nur geschrieben, wo die zugehörige Datei abgelegt wurde.

Damit benötigst Du keine Rechte mehr für "irgendwelche Normalbenutzer".

Und die Geschäftsleitung durchsucht die Dateien gefälligst nicht mehr mit dem Explorer, sondern eben auf mit dem Programm oder bekommt notfalls ein eigenes Programm, dass die Datenbankinhalte explorerähnlich darstellt und bekommt dann von dem Programm ggfls. die Dateien zur Ansicht geliefert. (Und die Suche nach Inhalten in diesen Größenordnungen könnte durch gezielte Auswahl per Select * from wasauchimmer where wiebitte = suchmirdas dürfte da eventuell deutlich effektiver werden.) Die Geschäftsleitung könnte dadurch also durchaus auch profitieren. (Und keiner von denen kann mehr irgendwas versehentlich per Explorer verschieben, löschen ...) Eine ggfls. erforderliche Revisionssichertheit könnte dadurch steigen.

Pflapsig formuliert: Die umständliche Rechtevergabe auf Dateiebene lagerst Du aus in eine Rechtevergabe auf Datenbankebene.

Damit benötigst Du (vermutlich) nur noch einen Datenbankbenutzer. Wer wann was zu sehen bekommt oder schreiben darf, ergibt sich aus der im Programm implementierten Geschäftslogik.

Wenn das Programm schon über ein sinnvolles Berechtigungssystem verfügt (muss man sich beim Programmstart dort irgendwie Anmelden oder eher Doppelklick zum Programmstart und man darf loslegen?), so dürfte der Aufwand vertretbar und überschaubar sein.

Möglichkeiten, wie das Programm die Daten an die in der Datenbank vermerkten Stelle bekommt, wurde schon beschrieben. Das Programm macht das eben nicht selbst, sondern bittet eine andere Software, dies zu übernehmen. Nur diese Software (Webserver, Dienst ...) benötigt dann Rechte im Filesystem.

[Kostas]

Aktuell habe ich den Zustand dass die Anwendung die Berechtigung der User wehr was darf verwaltet. Auch in der DB steht der relative Link zu den Dateien und das protokollieren ist umgesetzt. Das alles funktioniert schon seit vielen Jahren. Das Projekt ist noch ein Delphi 5 Projekt und kann nicht einmal hochgezogen werden wegen Fremdkomponenten. Ich verwende auch die versteckteFreigabe$. Der normale sterbliche Anwender kommt sicherlich nicht drauf. Ein etwas erfahrener, sagen wir mal Poweruser würde irgendwann mal schon drauf kommen. Aktuell läuft es schon seit mehreren Jahren so. Es gab in derzeit zwei Anwender die aufgeflogen sind weil Sie solche geheime Informationen an Mitbewerber weitergegeben haben. Durch die Logs hat man den Zeitraum eingegrenzt und die Dokumenten gefunden die das Haus verlassen haben.
Die Sache mit dem Netzlaufwerk verbinden funktioniert schon. Ist auf jeden Fall besser als die $-Freigabe. Ich werde das jetzt mal einbauen und schauen was passiert und wie zuverlässig es funktioniert. Ob es vorkommt dass ich mitten drin doch keine Schreibrecht habe u.s.w.

Herzlichen Dank und eine schöne Zeit an alle.
Gruß Kostas

[p80286]

Der Drops ist zwar gelutscht, aber ich muß noch eine Bemerung los werden.

Zitat von Delphi.Narium:

Damit benötigst Du (vermutlich) nur noch einen Datenbankbenutzer. Wer wann was zu sehen bekommt oder schreiben darf, ergibt sich aus der im Programm implementierten Geschäftslogik.

Das kann sich zwar ergeben (ein Datenbankbenutzer) aber ist meiner Meinung nach nicht erstrebenswert. Sobald es nur noch einen Benutzer gibt und irgendein neugieriges Wesen die UID und das Passwort in die Hände bekommt, steht die DB ihm offen. Für jeden Benutzer eine DB-UID bedeutet zwar einen (stark) erhöhten Verwaltungsaufwand, aber zumindest besteht auf DB-Seite immer die Möglichkeit des detailierten Loggings.
Über Gruppen und Views kann man dann verschiedenen Nutzern vollkommen unterschiedliche Datenbanken vorspiegeln.
Das ist zugegebener Maßen nicht ganz trivial, aber meiner Meinung nach sicherer als die Oneforall-Lösung.
(Wir hatten so zwei geographisch unterschiedliche Benutzergruppen vollständig gegeneinander abgeschottet)

Gruß
K-H

[Delphi.Narium]

Prinzipiell ok, aber damit sind wir wieder bei der Frage: Wieviel Aufwand wollen wir treiben.

Das mit dem einen Nutzer meinte ich auch eher in Bezug auf die Kommunikation zwischen Datenbank und Filesystem.

Das ein Anwender auf der Datenbank selbst nur das darf, was seinen Anforderungen / seinem Job entspricht, sollte selbstverständlich sein.

[p80286]

Zitat von Delphi.Narium:

Wieviel Aufwand wollen wir treiben.

Na, der Aufwand sollte umgekehrt proportional zu den Anforderungen sein

Gruß
K-H

[jobo]

Zitat von p80286:

Der Drops ist zwar gelutscht, aber ...

Das kann sich zwar ergeben (ein Datenbankbenutzer) aber ist meiner Meinung nach nicht erstrebenswert.

Das würde ich auch gern betonen. Es hieß ja hier nicht zu Unrecht mehrfach, dass damit (DB Lösung) die Rechteproblematik gut zu lösen ist. Das ist erstmal klar, die verschiedenen DB bringen je nach Mächtigkeit einen riesigen Berg an Rechteverwaltungs und Monitoring / Auditing Möglichkeiten mit und zwar implizit.
Würde heißen, selbst wenn ein User mit seinem Login direkt in die DB einsteigt, werden seine Zugriffe genauso gelogged wie von außen (es gibt aus DB Sicht einfach keinen Unterschied), ebenso gilt das für die "Sichtweite" des Users

Verwendet man nur einen DB User dazu, wäre das so ungefähr selbstgewähltes Eunuchentum.
Dass man diese Berechtigungsstruktur nicht erneut zwischen DB Modell und DB Dateisystem einzieht, dürfte mehr oder weniger klar sein.

Zuletzt: Das macht in dieser Form aber auch nur Sinn, wenn man halbwegs komfortabel mit 2-3 Stored Procs arbeiten kann.
Ansonsten bleibt via DB die stumpfe Datei-in-BLOB-Speichern Variante mit Plain SQL, die aber ohne Weiteres nicht sehr "browsig" für die GF da steht.