[PATCH] - vorschlag attribut allowedDevices

[justme1968]

mit dem angehängten patchvorschlag wird ein neues attribut allowedDevices eingeführt das man analog zu allowedDevices setzen kann.

in der betreffenden web oder telnet instanz sind dann die nicht gelisteten devices so weit wie möglich für kommandos verborgen. d.h. sie werden beim devspec2array aufruf der durch ein kommando ausgelöst wird ignoriert. im frontend ist das device aber weiterhin sichtbar kann aber nicht bedient werden. einem bedien tablet kann so z.b. die bedienung der devices im eigenen zimmer erlaubt werden statt wie bei allowedCommands die bedienung aller devices zu verbieten.

der patch ist vermutlich noch nicht ganz vollständig da es eventuell noch kommandos gibt die direkt $defs abarbeiten ohne devspec2array zum nutzen. ich habe nur list, xmllist und jsonlist2 angepasst.

eventuell ist es auch sinnvoll den loglevel auf 4 zu ändern.

gruss
  andre

ps: das ganze ist angeregt durch die aktuelle security diskussion und ja: es ist nur ein (weiterer) kleiner baustein.

[rudolfkoenig]

Ich habe prinzipiell nichts dagegen, ich moechte aber dein Vorschlag nicht implementieren, weil mAn mittelfristig im Weg steht.

Habe ueber eine "richtige" Loesung nachgedacht, hier ist mein bisheriger Stand:
- Modul allowed, implementiert AuthorizeFn. Ist fuer Authorisierung via allowedCommands und allowedDevices zustaendig. Andere Module duerfen andere Strategien haben.
- die AuthorizeFn aller Instanzen wird an den noetigen Stellen von fhem.pl mit $cl aufgerufen, Reihenfolge ist immer gleich.
- Rueckgabewert: 0:nicht zustaendig, 1:explizit zugelassen, 2:explizit verboten. Falls keiner zustaendig, dann geht Befehl in Ordnung.
- "noetige" Stellen: AnalyzeCommand (mit Argument cmd und perl/shell/commandname), devspec2array (mit Argument devicename und den eigentlichen Namen).
- allowedCommands/allowedDevices sind Attribute einer allowed Instanz.
- eine Instanz ist per Voreinstellung fuer alle Eingaenge (== FHEMWEB/telnet) zustaendig, oder fuer bestimmte (per Filter definierbar)
- danach allowedCommands aus FHEMWEB/telnet verbannen, weiss aber noch nicht, wie man das "schmerzfrei" machen kann. Evtl. mit featurelevel, das ist mir aber eigentlich zu langsam. Ich will dein Vorschlag nicht implementieren, damit man hier nicht noch mehr umbauen muss.
- die Authentifizierung (basicAuth/password) gehoert auch hierher (AuthenticateFn), damit man unterschiedliche Benutzer haben kann, habe dafuer aber auch keine "schmerzfreie" Idee.

Ungeloest: es ist nicht moeglich einem Benutzer das Definieren von at/notify/etc zu ermoeglichen, das nur bestimmte Geraete modifizieren kann. Aber vielleicht sollte man nicht alles auf einmal haben wollen.

[justme1968]

wenn ich deine idee richtig verstehe kann es dann mehrere allowed instanzen geben die unterschiedlich konfiguriert sind. z.b. eine für den administrator, eine für einen user und eine nur fürs kinderzimmer?

funktioniert das 'andere module dürfen andere strategien haben' wirklich? ist es nicht besser zumindest bestimmte vorgaben zu machen? z.b. es gibt user die rechte an bestimmten kommandos und bestimmten devices haben. do zu sagen als grundlage wie das in fhem funktioniert und fhem stellt über die allowed instanzen alles nötige dafür zur verfügung. die module würden dann 'nur noch' das mapping ihrer rechte/rollen/gruppen auf eine passende allowed instanz machen.

mir ist aber noch nicht klar wie du die jeweiligen web/telnet/... instanzen mit der zuständigen allowed verbinden willst. irgendwas fehlt noch. oder steckt die AuthorizeFn jeweils im web/telnet/... device?

das mit dem at/notify/... könnte man erst mal auf modify beschränken und hier die rechte an den parametern prüfen. damit könnte man z.b. das ändern der uhrzeit für einen wecker erlauben. aber verbieten das plötzlich jemand perl code in ein notify schreibt das er ändern darf. oder man sagt diese at/notify/... müssen vom administrator so definiert werden das sie die nötigen parameter aus einem dummy holen und der anwender hat nur rechte diesen dummy zu ändern.

[justme1968]

es gibt noch ein szenario das schön wäre mit abzudecken.

angenommen eine fhemweb instanz hat mehrere httpserv devices definiert um unterschiedliche tablets im haus mit einem bedien ftui panel zu versehen.

idealer weise kann man jetzt auf mehreren tablets die gleiche ftui konfiguration mit verschiedenen rechten verwenden und unterschiedliche konfigurationen mit den gleichen rechten. also eine n:m beziehung die aber an der httpserv instanz hängt und nicht an der fhemweb instanz.

und noch etwas: die möglichkeit sich an einer verbindung für eine gewisse zeit als neuer user anzumelden. -> das panel im flur hat bestimmte rechte, der admin sich aber an der bestehenden verbindung anmelden und etwas konfigurieren, danach (automatisch?) wieder abmelden. ohne das der das bestehende frontend wechseln oder eine andere url aufrufen muss.

hintergrund: das tablet läuft im kiosk mode und darf nur auf eine bestimmte ftui url zugreifen.

ähnlich: alarmanlage unscharf schalten mit pin.

[rudolfkoenig]

funktioniert das 'andere module dürfen andere strategien haben' wirklich?

Ich vermute du hast noch was anderes im Kopf.
Sicher kann man z.Bsp. ein Auth-Modul vorstellen, wo man nicht die Befehle und die einzelnen Geraete spezifiziert, sondern Benutzer mit Rollen und Raeumen, usw.

mir ist aber noch nicht klar wie du die jeweiligen web/telnet/... instanzen mit der zuständigen allowed verbinden willst.

Code Auswählen Erweitern

define telnet1 telnet 7072 global
define web1 FHEMWEB 8083 global

define telnetAuth allowed
attr telnetAuth validFor telnet1
attr telnetAuth authToken { "admin:geheim" }

define webAuth allowed
attr webAuth validFor web1
attr webAuth allowedCommands set,get,list,modify
attr webAuth allowedDevices room=Kinderzimmer

idealer weise kann man jetzt auf mehreren tablets die gleiche ftui konfiguration mit verschiedenen rechten verwenden

Wenn man ueber eine Eingangsinstanz unterschiedliche Regeln anwenden moechte, muss das Auth Modul ein Benutzerkonzept unterstuetzten. Deswegen faende ich sinnvoll, ein AuthenticateFn zu haben. Das muss aber nicht unbedingt ins gleiche Modul, und mAn auch nicht gleich ins allowed. Ich haette naemlich gerne was Einfaches fuer den Anfang.