Fallstricke der Benutzerverwaltung

[susigross]

Ich weiß nicht, ob das jedem bewusst ist, habe mal meine Erkenntnisse dazu zusammengefasst:
http://wbdemo.heysoft.de/pages/de/fallstricke/zugriffsrechte.php

[Waldschwein]

Hallo!

Ja, ich war mir später auch bewusst, dass es nicht nur Sonnenseiten gibt, als ich den damaligen Addonschreiber des Multiple Group Addons für WB 2.6.7 http://wb-mods.lism.catholic.edu.au/pages/patches.php "tavitar" (er scheint mittlerweile nicht mehr aktiv zu sein...) genötigt habe, das ganze für WB 2.7 in den Core reinzunehmen. 

Prinzipiell sollte man eben immer aufpassen, wem man welche Rechte vergibt, und generell niemandem welche geben, dem man nicht traut. Wobei ich mich ehrlich frage, ob es WB Installationen gibt, die als Groupware fungieren, aber man weiß es ja nie... Wie es halt immer so ist bei Addons wie auch dem Multiple Group sind es halt doch nicht Sachen, die von vorne herein so werkeln wie sie sollten. Aber ich hoffe, dass man in Zukunft einmal sich das gesamte Rechtesystem genauer ansieht, da es wie du schon sagst gewisse Logikfehler aufweist, und häufig auch viel zuviele Schritte notwendig sind, wenn etwas nachträglich geändert werden soll.

Also: Wem man nicht auf menschlicher Basis traut, gibt man generell keinen Zugang zum Backend, und ich würde das nicht nur bei WB so machen.

Gruß Michael

[susigross]

Wobei ich mich ehrlich frage, ob es WB Installationen gibt, die als Groupware fungieren

Die gibt es ganz sicher, sogar mit Benutzerverwaltung im Active Directory 
AMASP ist ja auch eine (wobei dort sicher jeder User nur in einer Gruppe drin ist)

[Luisehahne]

Aber ich hoffe, dass man in Zukunft einmal sich das gesamte Rechtesystem genauer ansieht, da es wie du schon sagst gewisse Logikfehler aufweist,

Da kannst du einen drauf lassen

Dietmar

[doc]

Hi Frank,

schöne Zusammenfassung.

Vor längerer Zeit war mal ein Admin Tool angedacht, welches beim "Umschiffen" des von Dir beschriebenen Fallstrickes Nr. 2 Abhilfe schaffen sollte. Sprich für bereits vorhandene Seiten weitere Gruppenrechte hinzufügen oder entziehen (einzelne Seiten, Seitenäste, alle Seiten). Das Tool wurde soweit ich weiss aber nie in Angriff genommen.

Die sauberste aller Lösungen ist aber sicherlich eine überarbeitete Benutzerverwaltung, wie Luisehahne in Aussicht gestellt hat. Vielleicht ein nettes Feature für WB 3

Gruss Doc

[LordDarkman]

ich kenn mich in der rechteverwaltung nicht wirklich aus aber könnte man nicht viel umgehen indem man von anfang an alles verbietet/nicht in DB einträgt.
in Zeile 53 der admin/groups/add.php hab ich folgendes gefunden:

Code: [Select]

$query = "INSERT INTO ".TABLE_PREFIX."groups (name,system_permissions,module_permissions,template_permissions) VALUES ('$group_name','$system_permissions','$module_permissions','$template_permissions')";
wenn man statt '$system_permissions' ' ' einträgt müsste der schonmal keine rechte mehr auf Seiten haben. Bei Modul Permissions und Template Permissions geht die Abfrage leider genau andersrum. Was eingetragen ist ist verboten. Wie man das "Schnell" umgeht k.a.

Bis denne dann Moritz

[susigross]

Es gibt Sicherheitsprobleme, die kann man nur mit Änderungen im Code lösen.
Und es gibt Sicherheitsprobleme, die kann man auch mit sorgfältiger Konfiguration lösen.
Um so eines handelt es sich hier (sonst hätte ich es nicht veröffentlicht), und diese Lösungsmöglichkeite n habe ich ausführlich beschrieben.
Irgendwann wird sicher das Berechtigungskonzep t im Code vom Kopf auf die Füße gestellt, dann braucht man die Kopfstände als Admin nicht mehr zu machen.

So schwer ist die Korrektur des Codes ja nicht:

• Whitelist statt Blacklist
• Nur die Rechte der Gruppen berücksichtigen, die überhaupt Admin-Rechte für die aktuelle Seite haben

[doc]

Hi,

auch wünschenswert. Wenn man auch die Berechtigungen zu einzelnen Admin Tools erlauben oder verbieten könnte. Bisher gilt mit Zugang zu den Admin Tools können alle Admin Tools verwendet werden, was aber oft nicht erwünscht ist.

Gruss Doc

[LordDarkman]

Mir ist beim testen mit der DB was anderes aufgefallen: Wenn ich rechte für Module rausnehme (Backend) werden diese in die db geschrieben. Lass ich das Feld in der db leer habe ich rechte dafür. Es scheint dem zu folge doch eine Blacklist zu sein (was steht ist verboten). Das würde auch erklären warum neu inst Module nicht von Werk aus verboten sind. Man müsste also bei Module und Templates das ganze umdrehen (was steht in db ist erlaubt, rest verboten). Dann würden neue Module installiert werden können, sie werden nicht in db gelistet und sind verboten. Bei den Seiten macht er das ja so. Wenn ich da in der db das Feld Lösche bzw das Script wie oben beschrieben ändere dann machrt er nichts (gibt keine rechte). Ich komm da zwar erst heute abend zu, aber ich hab eine Idee when ich gestern richtig die Scripte überflogen habe...

Bis denne dann Moritz

[susigross]

Es scheint dem zu folge doch eine Blacklist zu sein (was steht ist verboten).

Es hat keiner etwas anderes behauptet.

[LordDarkman]

Für die Rechteverwaltung wird eine Blacklist verwendet, auch wenn es im Backend so aussieht, als würden wir eine Whitelist verwenden.

Da war es wohl nioch ein wenig früh am morgen für mich... Hab das ein wenig verdreht. Sry!

Nich desto trotz hab ich immernoch eine idee und sobalt ich wieder an einem PC sitze und nicht übers Handy im Forum stöber werd iich die mal nachschlagen.

Bis denne dann Moritz

[WebBird]

Ich persönlich glaube ja, WB wurde ursprünglich nur für einen Benutzer (Admin) konzipiert. Später dachte man dann wohl, weitere wären auch nicht schlecht, die sollten dann aber auch erst mal alles können, außer... So, und schon war das Kind im Brunnen. *g*

Für 2.x kann man das nicht mehr vernünftig ändern, für 3.x aber ganz sicher. Ich sag nur "Bitmaske". *ggg*

[Waldschwein]

Ich persönlich glaube ja, WB wurde ursprünglich nur für einen Benutzer (Admin) konzipiert.

Och, wer eine WebsiteBaker Version vor der 2.5 einmal live gesehen hat, der weiß, dass da so einiges gefehlt hat oder anders gedacht war... So weit ich weiß gab es bei 2.0 noch keine Mehrsprachigkeit, also alles schön Englisch hardgecodet.   Und ich wage zu behaupten, dass es da auch noch keine Benutzer und Gruppen gab, oder es hat noch nicht funktioniert...