[Allegro] Janas und access
Thomas Berger
ThB at Gymel.com
Do Dez 11 12:41:31 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lieber Herr Eversberg,
>> Auch unabhaengig von Janas muessen Exflexe insbesondere bei
>> niedrigen access-Werten moeglich sein, ...
>
> Wie bitte? Dann wird der FLEX-kundige Saboteur einen ExFLEX an sein
> mit access=0 laufendes a99 senden und es zu sonstwas veranlassen.
Ich bleibe dabei: Fuer gewisse Mitarbeiter wird man ganz
deutlich eine Situation von moeglichst geringem access-Level
und gleichzeitig moeglichst grossem Komfort / starker
Kanalsierung der Arbeitsablaeufe einsetzen wollen. Und da
gehoeren m.E. gerade Janas und ExFlexe unbedingt dazu.
Eine Situation, wo Fachpersonal mit access=2 auskommt, Aushilfen
jedoch wegen erleichterter Fremddatenuebernahme zwingend
access=4 benoetigen, halte ich fuer nicht tolerierbar.
> Genau wegen solcherart spitzfindiger Bedenken, von Ihnen geäußert, haben
> wir doch überhaupt an diesen Sachen gedreht, sonst hätten wir jetzt
> nicht diese neue Kalamität.
Man wird (sowohl fuer Janas als auch fuer Exflexe) sich noch
einmal ueberlegen muessen, welche Aktionen "autorisiert" sein
sollen. a99-intern ist es ja momentan so geloest, dass auch
Eingabe von "X" im Schreibfeld bei niedrigen (z.B. 3!)
access-Werten abgefangen wird, hingegen alles, was irgendwie
in eine der ueber 500 Hilfeseiten eingebunden ist, erlaubt
wird. Als Zusatzmechanismus koennen Flexe selbst auf das
access-Level testen und entsprechend reagieren, und die
RTF-Hilfeseiten koennen sich selbst an gewissen Stellen
"abschneiden" (dieser Mechanismus hat kein Pendant in Janas
und bei Exflexen).
Zudem gibt es Grenzfaelle bei der Unterscheidung zwischen
"manuell ausgeloest und daher auf notwendige Zugriffsrechte
zu testen" und "automatisch im Zuge einer autorisierten
Verarbeitung ausgeloest", v.a. bei Aktionen, die ueber
"X"-Zeilen in .vw-Dateien (und bei aresqa?) spezifiziert
sind, oder auch bei Flex-Aufrufen in Phrasen.
Wenn es gelingt, die Situationen "manueller Ausloesung" exakt
zu bestimmen, koennten Flex-Dateien analog den RTF-Texten
z.B. mit einer Kennung "_5 Sorry, Ihre Rechte reichen nicht aus"
versehen werden, diese muss vor der ersten Nicht-Kommentarzeile
stehen, fehlt sie (!), oder ist der angegebene Wert zu niedrig,
wird die manuelle Ausloesung (oder der Exflex, oder die
Janas-Aktion) verweigert. Das kann dann auch dabei helfen,
a99-intern die Ausfuehrungsautorisierung von den Zufaelligkeiten
der Erwaehnung in irgendeiner .RTF-Datei abzukoppeln.
Es setzt allerdings voraus, dass sich Flexe quasi universell
gewissen Gefaehrdungsstufen zuordnen lassen, denn es ist zu
vermeiden, dass Anwender staendig Standardflexe auf ihre
eigene Rechteverwaltung zurechtbiegen muessen. Erfahrungsgemaess
ist es auch recht schwierig, das Datenverzeichnis gegen
Schreibzugriffe abzusichern, man wird dieses Verzeichnis
aber nicht aus der automatischen Suche nach Flexen herausnehmen
wollen, schliesslich ist es der einzige Ort, an dem man ohne
groessere Zusatzlogik datenbankspezifische Verarbeitungen
hinterlegen kann.
Auch denkbar waere, fuer janas bzw. Exflex erlaubte .flx-Dateien
explizit zu sanktionieren, indem man sie nur dann zur Ausfuehrung
erlaubt, wenn sie in speziellen Unterverzeichnissen des Programm-
Verzeichnisses liegen. Aus a99 ausloesbare init-Funktionen muessten
dann allerdings dafuer sorgen, dass "vorgesehene" Aktionen (wie etwa
die Schnellkopplung) durch flex-gesteuertes Kopieren des relevanten
Flexes ermoeglicht werden): Auch etwas heikel, weil es das
Datenverzeichnis komplett ausschliesst und Flexe staendig kopiert
werden muessen, damit nicht ein Upgrade der Installation veraltete
"Arbeitsversionen" der Flexe zuruecklaesst.
Weitere zu untersuchende Mechanismen waeren vom Administrator zu
pflegende Listen von autorisierten Flexen, Integration in die
Benutzerverwaltung (_passwd.flx und zugehoerige geschuetzte
Verzeichnisse) oder die Einfuehrung "universeller" Saetze in den
Datenbanken zu allen Konfigurationen bzw. Einstatz der urspruenglich
fuer phpac kreierten user-Datenbank...
viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSUD8a2ITJZieluOzAQKfbgP+MI20UOJaZ/i9kvGYkzw5RjwRWlmT2YCI
Y6FNE4T4RATSKCIqqD8y7dnWOzpU/mxe5xGkmnjbO7swPlU7CZlWmOuhIzwBiUCH
vNtJM9XbeQP7uDaXXMH/aSisT6XZVAA1DIaLK6aZBleCfciJHJVjx6jKHO2BF7lY
fetCdQeePyw=
=T5zb
-----END PGP SIGNATURE-----
Mehr Informationen über die Mailingliste Allegro