Du bist nicht eingeloggt! Möglicherweise kannst du deswegen nicht alles sehen.
  (Noch kein mods.de-Account? / Passwort vergessen?)
Zur Übersichtsseite
Hallo anonymer User.
Bitte logge dich ein
oder registriere dich!
 Moderiert von: Atomsk, Maestro, statixx, Teh Wizard of Aiz


 Thema: Software-Entwicklung 0 ( new SammelThread() )
« erste « vorherige 1 ... 32 33 34 35 [36] letzte »
erste ungelesene Seite | letzter Beitrag 
hoschi

hoschi
Crosspost aus Linuxforum
Originalpost

Ich knobel hier ein einem Rätsel. Warum ist globale Variable optarg von getopt() im GDB verdeckt? Ich verstehe es nicht. Für getopt() benötigt man den Header unistd.h, welcher getopt_posix.h und schließlich getopt_core.h inkludiert.

Deklaration im Header
 

/* For communication from 'getopt' to the caller.
When 'getopt' finds an option that takes an argument,
the argument value is returned here.
Also, when 'ordering' is RETURN_IN_ORDER,
each non-option ARGV-element is returned here. */

extern char *optarg;



Definition im Source
 

109 /* For communication from `getopt' to the caller.
110 When `getopt' finds an option that takes an argument,
111 the argument value is returned here.
112 Also, when `ordering' is RETURN_IN_ORDER,
113 each non-option ARGV-element is returned here. */
114
115 char *optarg = NULL;



Deklaration und Definition sehen für mich fein aus.

Mache ich einen Denkfehler? Kann ich GDB darum bitten mir den Ort eine Variablendeklaration anzuzeigen, also in welcher Datei das optarg deklariert ist. Was mir auffällt, ich bekomme für p &optarg eine andere statische Adresse als für p &'optarg@GLIBC_2.2.5'.
13.10.2021 11:33:53  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
MQTT & Co.: Wie wird in der Praxis ""Sicherheit"" umgesetzt? Im Standard kommt das ja nirgends vor, abseits von Clients die sich halt anmelden. Aber wenn ich jetzt z.B. einen Broker habe, scheint MQTT erstmal davon auszugehen, dass jeder Client der auf den Broker darf überall publishen und subscriben darf. Wenn ich Request-Response per Correlation Data abbilde, kann jeder Client meine Response sehen. Mosquitto scheint ACLs zu haben, aber irgendwie fühlt sich das ganze nicht so an, als ob es dafür gedacht wäre, dass man nicht vertrauenswürdige Clients an den Broker lassen soll (sondern eher nach "dem Ding da hinten im Backend"), etwa wenn man Daten nach Nutzern aufteilen möchte. Ist die Idee hier, dass man für solche Clients letztlich irgendeine Form von Gateway/Anwendung davorschaltet, die Authz umsetzt?
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.10.2021 18:42]
13.10.2021 18:40:50  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[smith]

AUP [smith] 29.07.2010
Verstehe nicht genau was du für ein "Level" haben willst... Normalerweise haben die Message Broker selber ja eine ACL, wie Mosquitto auch. Unter Authentication in der Doku hast du ja viele Möglichkeiten aufgezählt: https://mosquitto.org/man/mosquitto-conf-5.html . Dazu gehört z. B. auch, dass Clients ein gültiges Zertifikat beim Verbinden zeigen müssen. Meinst du das?

Ansonsten kannst du natürlich auch deinen Payload beliebig verschlüsseln und den Schlüssel beliebig komplex an berechtigte Clients rausrücken. So macht man es halt generell noch "zusätzlich" wenn man sich um den Inhalt wirklich kümmert.

Vielleicht spannender Anwendungsfall: Firma XYZ fährt voll auf Event-Sourcing ab, muss aber gleichzeitig den deutschen e: GDPR Datenschutzgesetzen genügen. Sprich ein Kunde kann die Löschung aller seiner Daten verlangen. Ist natürlich schwierig, wenn man irgendwo Eventstores rumstehen hat mit ewiger Retention Time.
Eine Möglichkeit ist es dann z. B. den Nachrichteninhalt benutzerspezifisch zu verschlüsseln und bei Löschwunsch schlicht den Key wegzuwerfen, womit alle Nachrichten "unbrauchbar" sind. Siehe Vorschlag hier: https://doc.akka.io/docs/akka-enhancements/current/gdpr/index.html#introduction (bitte prüfen ob alle Bedingungen erfüllt sind).

Hilft das oder kannst du die Frage präzisieren?
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von [smith] am 13.10.2021 20:09]
13.10.2021 19:31:49  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
DAS ist dsgvo konform???
13.10.2021 19:54:21  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[smith]

AUP [smith] 29.07.2010
 
Zitat von Oli

DAS ist dsgvo konform???


Hmm, evtl. habe ich übertrieben (korrigiere den Post), aber zumindest für GDPR-Compliance suggeriert mir diese Doku, dass die Methode reichen könnte.

Aber das Datenschutzthema ist natürlich komplizierter und ich bin da kein Experte, daher sollte man entsprechend genau prüfen. Es sollte eher ein Beispiel sein wie er den Inhalt seiner Daten zusätzlich schützen kann.
13.10.2021 20:08:01  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
Ich bin da noch in der "konzeptionell verwirrt"-Phase, wo mir noch nicht klar ist, wie man Dinge abbildet - meine Fragen sind also nicht so super-konkret, sondern eher beim Bauchgefühl: Ist die Technik dafür gedacht / bereit, dass ich das als direkte Schnittstelle zu Clients, die im Feld von Kunden betrieben werden, nehmen kann. Quasi eine Einordnung zwischen "Shellzugriff" (Wenn ich Nutzer/Kunden auseinanderhalten möchte, wickle ich dann meine Schnittstelle per SSH-Zugriff und Befehle ausführen ab? Eher nicht) und REST-API.

Konkrete Frage: Wie würde man denn ein Request-Response-Schema auf MQTT sicher abbilden? Ich stelle mir das irgendwie so vor:
- Der Request geht an ein Topic was dem Service gehört, z.B. services/foo
- Jeder Nutzer hat einen privaten Topic-Baum, z.B. users/$USER, und benutzt da dann einen Topic als Response-Topic
- Services sind auf users/* berechtigt und können dort dann die Response publishen, aber
- Nutzer sind nur auf users/$USER berechtigt, können als nur an sie gerichtete Responses erhalten.

Beispiel fortgeführt: Nutzer lässt einen Service irgendeine Ressource per Request-Response erstellen und dann sollen Nachrichten bzgl. der Ressource ausgetauscht werden. Würde man das so machen, dass der dahinterstehende Service dann dynamisch die ACL vom Broker ergänzt, sodass der Nutzer die dazugehörigen Topics zugreifen kann?
13.10.2021 20:29:14  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
NI-Xpert

Arctic
Das klingt für mich eher nach "Ich habe hier den MQTT Hammer und suche nun den passenden Nagel"
Wenn aber alles schon implementiert ist und läuft und du baust was dazu um dich zu integrieren dann fände ich es sinnvoller Authentifizierung und Autorisierung auszulagern und die eigentliche Verbindung über nen Proxy laufen zu lassen. Zum Beispiel kann per REST Call der Proxy mit entsprechender Firewall und den korrekten Subscriptions aufgesetzt werden und dann kann sich der Client mit Standardmitteln verbinden und kriegt nur die Topics die er darf. Der Proxy blockiert dann alle Commands die nicht erlaubt sind.

Vielleicht verstehe ich das Problem aber falsch
13.10.2021 21:06:09  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Viva la Bluescreen

AUP Viva la Bluescreen 31.01.2008
Hm - unser RMQ hat jetzt nicht so wirklich viel mit Nutzerdaten zu tun, aber wir nutzen RMQ sehr stark im Backend quasi als Transportschicht im ESB.

Die angeschlossenen Services nutzen die RMQ ACL um nicht pauschal jegliche Events zu bekommen. Die Payload an sich ist unverschlüsselt.

Die Services selber sind dann halt abgesichert, also bei einer REST-Api entsprechend mit https + Token und je nach UseCase gibts auch Services die wiederum ein eigenes UserManagement haben. Bei den Recherchen dazu bin ich tatsächlich nie über User basierte Exchanges oder topics in RMQ gestolpert sondern entweder Applikations/Service getrieben oder auf Datentypen getrimmt. Spräche dafür dass in diesen Fällen jeweils der ans RMQ angeschlossene Client alles im Rahmen der RMQ ACL bekommt und dann eben selbst dafür sorgen muss dass jeder nur die korrekten Daten bekommt.

Wir haben bei uns nur einen Ausnahmefall wo eine dritte Partei direkt an unseren RMQ darf - da hat uns die ACL im RMQ ausgereicht dass diese Partei nur wenige Queues sehen und abgrasen darf.
13.10.2021 23:03:46  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[smith]

AUP [smith] 29.07.2010
Das ist bei uns auch so, direkt an die Queues selber darf bei uns niemand Externes dran. Alle externe Zugriffe werden über eigene spezialisierte Services abgehandelt, die dann entsprechende passende Authentifizierungsmethoden haben.

In unserer Welt hatte das alleine den Vorteil, dass wir so Event Evolution im Hintergrund machen können, während die Schnittstelle zum Kunden erstmal stabil bleibt.

Dazu können wir auch an nötigen Stellen Aggregation/Snapshotting/Transformationen/Caching, ohne dass das MQ System es selber unterstützen muss, sprich es gibt weniger Vendor-Lock. Da alle Services einen lokalen Eventstore haben für verschiedene Zwecke kann auch das MQ System im Hintergrund abrauchen, merkt der Kunde erstmal nichts von (bis auf möglicherweise veraltete Daten natürlich).

Ich will auch gar nicht sagen dass es eine zwingend gute Lösung ist. Nach dem zweiten Wechsel des Queue-System sind wir aber davon abgekommen, "komplizierte" Features damit umzusetzen, die die Eventwelt verlassen. Hat eine unglaubliche Kackarbeit an Migration jeweils verursacht. Und dynamische Topic-Erstellung/Bereinigung war in unserem System nicht realistisch umsetzbar. Dazu hat es sich für uns als wartbarer herausgestellt, weniger Topics mit anschließender Filterung im Service selber zu haben, also ewig viele Topics, die einzeln konsumiert wurden und langsam die Connection-Pools weggefressen haben.

Müssen deine Nutzer den zwingend Zugriff zu den Live-Daten haben? Können sie die überhaupt verarbeiten und mögliche Zustände selber herleiten? Wenn du die Event-Struktur änderst, klappt das für alle Nutzer gleichzeitig?

Aber ja, ich kenne auch Beispiele wo eine ACL dynamisch ergänzt wurde, quasi wie iptables-Einträge. War schwierig zu durchschauen und debuggen
13.10.2021 23:37:22  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Tenz

AUP Tenz 03.04.2009
Kenne den typischen Einsatz von RMQ auch nur als async Transportschicht für Event & Delegations innerhalb geschlossener Systeme bzw. bis jetzt auch noch nicht im Zusammenhang mit dem Transfer von sensiblen Daten zwischen verschiedene willkürlichen remote Services über das Grundlegende „da darf ich ran“ hinaus. (Bezieht sich so aber nur auf den Anwendungsbereich E-Commecre und Caching sowie Hintergrundaufgaben und Schnittstellen zu div. rechenintensiven aber nicht zeitkritischen Services).

Spontan würde ich sagen, dass ausserhalb deiner inneren Domain, der Broken zwischen deinen Services eher für das ob, welches und wohin genutzt werden sollte und nicht für das wie und was.

Also sagen wir du hast Client X und Service Y. In der Mitte der Broker.

X schickt per Broker die Anfrage zu Topic N, Topic N ist Service Y Domain, also geht raus, dass Service Auth prüfen soll ob Client X das Topic N von Service Y erhalten darf, Service Auth aus sagt dem Broker dass Service Y Topic N an X liefern darf (ggf. weiss der Broker das auch dank ACL selber) -, Broker informiert Service Y darüber die Daten bereitzustellen, Broker sorgt intern dafür dass die Daten zwischen Service Y und Service IO, C und S gequeued über den Broker bearbeitet werden, Service S informiert Broker darüber dass die Daten von Topic N nun (warm) bereit liegen, Broker gibt Client X bescheid, dass die Daten abgeholt werden können ->(hier kommts) Client X holt sich die Daten per geschlüsselter Verbindung direkt von warmen Endpoint, ggf. informiert es dem Broker noch darüber dass die empfangen wurden.



Finds sehr spannend, gibt sicher legitime Anwendungsfälle für den Transfer der Daten an sich, in der Praxis aber noch nicht begegnet bis jetzt.
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von Tenz am 14.10.2021 0:16]
13.10.2021 23:50:08  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Admiral Bohm

tf2_spy.png
Im IOT-Bereich ist MQTT ein Ding um großflächig events von low-power-systemen einzusammeln. Bei AWS gibts dafür x.509-Authentifizierung für jedes Thing individuell. Diese Teile senden auch nur asynchron Daten und machen selten request/response.

Als größeren API-Ersatz fände ich es auch eine seltsame Anwendung, da gibt es bessere, funktionierende Lösungen.
14.10.2021 9:07:56  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
GH@NDI

ghandi2
MQTT taugt als Publish-Subscribe-Plattform sehr gut (wie Admiral sagt: Jedes zweite MQTT-Beispiel published Sensordaten in topics wie "/rooms/2nd-floor/bathroom").

Wenn du eh Request-Response hast und eben nicht "fire and forget" würde ich mir nochmal Gedanken machen, ob du in Wirklichkeit nicht auch etwas nutzen willst, das darauf aufbaut. Z.B. gRPC und dann halt ne Service-Discovery fürs LoadBalancing/Redundanz.

Je nach verwendeter Sprache gibts für gRPC auch coole Wrapper/Erweiterungen für die gängigen Geschichten wie retries, rate-limiting, circuit-breaker, yada yada (I'm looking at you Polly (.net core))
14.10.2021 9:19:51  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
Erstmal vielen Dank für die ganzen Antworten!

Das ist alles noch ganz frühe Planungsphase, ob überhaupt was dabei rumkommt steht noch in den Sternen. Breites Grinsen Mit euren Input geht's jetzt eher Richtung klassischerer Architektur, also Broker in der Mitte, AuthZ der Nutzer am Perimeter, Rollen am Broker sind Service-Rollen, nicht Nutzer, Berechtigungen entsprechend weitgehend statisch. Anbindung der Clients via Frontend/Gateway/Proxy, Protokoll zu den Clients (die kommen auch von uns, die Clients haben wiederum ein Interface was die Kunden nutzen) mal schauen - aber wahrscheinlich ergeben sich da aus diversen externen Zwängen (wie wir AuthN tun müssen, nur einen Port benutzen, muss TCP sein, am besten multiplexfähig...) eh nur wenige Kandidaten.
15.10.2021 18:06:40  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
 Thema: Software-Entwicklung 0 ( new SammelThread() )
« erste « vorherige 1 ... 32 33 34 35 [36] letzte »

mods.de - Forum » Public Offtopic » 

Hop to:  

| tech | impressum