Samba 4.16 vs Dolphin/Nautilus

[schmidicom]

Der eine oder andere wird es vielleicht schon bemerkt haben das es ab Samba 4.16 Probleme beim Zugriff auf Windows-freigaben geben kann. Mich hat das besonders getroffen weil ich aufgrund meiner Arbeit halt sehr davon abhängig bin mit solchen Freigaben eben arbeiten zu können. Ursache ist wohl eine einzige Zeile Code in einer einzigen Library.

Aber in diesem Thread soll es jetzt nicht um einen Lösung oder einen Workaround für mich gehen (ich werde fürs erste halt einfach auf Version 4.15 bleiben) sondern um die davon ausgelöste Diskussion aus dem dazu gehörigen Bugreport:
Bug 14983 - NT_STATUS_ACCESS_DENIED translates into EPERM instead of EACCES in SMBC_server_internal

Vor allem der dreiunddreissigste Kommentar finde ich doch ziemlich "direkt". Allerdings ist mein Englisch nicht gerade das beste und vielleicht verstehe ich das einfach falsch.
Was halltet ihr davon?

[firefly]

Soweit ich das verstanden habe, ist das Problem hier dass durch eine kaputte krb5 konfiguration die Kommunikation mit einer krb5 instanz nicht funktioniert.
In älteren Versionen von samba wurde der NT_STATUS code "NT_STATUS_INVALID_PARAMETER" in den POSIX errorcode "EACCES" übersetzt.
In 4.16 wurde dass geändert und stattdessen wird der NT_STATUS code nach POSIX "EINVAL" übersetzt.
Und nach meinem Verständnis ist das auch die richtige Änderung, da die Validierung der Anmeldedaten überhaupt nicht vorgenommen werden konnte aufgrund des Konfigurationsfehlers.

Bisher haben wohl Nautilus und KIO angenommen dass sie nur EACCESS behandeln müssen. Vermutlich durch ausprobieren oder durch das lesen des codes. Denn laut Aussage von Jeremy Allison soll das wohl ein nicht dokumentiertes Verhalten sein.
Und dass jetzt Nautilus und auch KIO damit nicht klar kommen ist halt pech, wenn man sich auf ein nicht dokumentiertes Verhalten verlässt.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.

[mike155]

Blöde Situation. Ich kenne sie aus verschiedenen Perspektiven:

1. Man entwickelt eine Library, findet einen Fehler und möchte diesen beheben. Leider ändert sich dadurch das Interface. Die Anwender der Library beschweren sich, weil ihre Programme nicht mehr funktionieren.
   
2. Man entwickelt ein Programm, das eine Library nutzt. Plötzlich funktioniert das Programm nicht mehr, weil die Library das Interface geändert hat. Natürlich ist man sauer auf die Entwickler der Library.
   
3. Als Anwender eines Programms sind einem Libraries und Interfaces völlig egal. Man möchte einfach nur, dass das Programm funktioniert.
   

Meines Erachtens hat jeder ein Stück weit Recht.

Eine Lösungsmöglichkeit wäre, versionierte Interfaces zu verwenden. Bei größeren Software-Projekten wird das gelegentlich gemacht. Für eine Übergangszeit gibt es dann zwei Versionen einer Funktion. Im Company-Umfeld funktioniert das ganz gut. Es ist aber vermutlich nicht das richtige Vorgehen für Open-Source.

Was Kommentar 33 angeht: Ossification ist in der Tat ein Problem, das jeder kennt, der im Netzwerk-Bereich arbeitet oder Low-Level Libraries entwickelt. Dem muss man in der Tat recht offensiv entgegentreten.

Im Gegenzug sollte man als Entwickler von Netzwerk-Protokollen oder Libraries aber seine Interfaces so gut designen, dass möglichst wenig Änderungen erforderlich werden. Linus Torvalds ist ein gutes Vorbild. Seine Rants bzgl. Interface-Änderungen, die dazu führen, dass Programme nicht mehr laufen, sind legendär - und vermutlich ein Grund für den Erfolg von Linux (Beispiel "We do not break userspace"). Anwender lieben es jedenfalls, wenn ihre Programme auch nach Jahrzehnten noch einwandfrei funktionieren.

[schmidicom]

Ich muss zugeben das ich jetzt erst mal Google benutzen musste um herauszufinden was hier mit "Ossification" überhaupt gemeint ist.
Falls es anderen auch so geht hier ein Link dazu: https://www.fastly.com/de/blog/minimizing-ossification-risk-is-everyones-responsibility

[firefly]

@mike155 stimmt schon was du sagst nur scheinst du nicht bedacht zu haben, dass das bisherige Verhalten anscheinend nicht Dokumentiert sei und sich Nutzer der Library darauf verlassen haben dass es immer so sei.
Und undokumentiertes Verhalten kann man schlecht als Part des Interfaces sehen.

Und in diesem Falle wurde aus meiner sicht auch nicht das Interface an sich geändert. Wäre das Interface an sich geändert worden, dann hätten die Programme, welche die Library nutzen, überhaupt nicht mehr funktioniert. Bis zu dem Punkt dass sie wegen eines unbekannten Symbols überhaupt nicht gestartet wären.
Bzw. Eine neu Übersetzung der Programme wäre fehlgeschlagen.

Und dein Hinweis zu "We do not break userspace" passt hier nicht ganz, denn da geht es um Veränderungen an Interfaces an sich, wodurch sie sich nicht mehr so verhalten wie es ursprünglich auch so dokumentiert war.

Nur hier geht es um eine Änderung eines nicht Dokumentierten Verhaltens, wenn man der Aussage von Jeremy Allison glaubt.

Das ist grob vergleichbar mit UB (Undefined Behaviour) im C++ Standard. Wenn ein Compiler ein bestimmtes Verhalten für eine als UB definierte Regel implementiert und ein Entwickler/Programm sich auf dieses Verhalten verlässt so kann er sich nicht beschweren, wenn bei einem Update des Compilers oder Verwendung eines anderen Compilers sich das Verhalten ändert und dadurch das Programm nicht mehr so funktioniert wie erwartet.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.

[schmidicom]

Ich habe mir mal die Mühe gemacht nachzusehen auf wie viele Rückgabewerte/Fehlermeldungen der Dolphin (oder eher das KIO darunter) seit Samba 4.16 nun reagieren müsste. Und ich glaube die Datei gefunden zu haben wo die NT Status-Codes in Unix-Fehler übersetzt werden:
https://github.com/samba-team/samba/blob/master/libcli/util/errmap_unix.c

[schmidicom]

Da dies jetzt eine etwas wichtigere Ergänzung ist mache einen neuen Post und kein Edit:
Die Änderung die dem Dolphin den Zugriff auf Windows-Freigaben (SMB) verunmöglicht wurde auf Version 4.15.7 zurückportiert!
https://github.com/samba-team/samba/commits/samba-4.15.7/source3/libsmb/libsmb_server.c

Jemand eine Idee was ich als Nutzer jetzt machen soll???

[firefly]

[asturm]

Gibt es dazu überhaupt schon einen kde.org Bugreport?

[schmidicom]

[schmidicom]

Nur zur Info:
Inzwischen gibt es im Bugreport von KDE einen Pull Request der das ganze wieder benutzbar macht.