staging.inyokaproject.org

Ganz so verstehe ich das obige Zitat nicht.

Set the permissions on /usr/local/samba/lib/usershares to 01770. (Owner and group all access, no access for others, plus the sticky bit, which means that a file in that directory can be renamed or deleted only by the owner of the file)...

Dies betrifft doch nur das Verzeichnis /usr/local/samba/lib/usershares bzw /var/lib/samba/usershares, in dem sich die Konfigurations-Dateien der Persönlichen Freigaben (entsprechend den Einträgen in smb.conf bei Allgemeinen Freigaben) befinden. Dies bedeutet doch nur, dass niemand außer dem freigebenden User, also dem Eigentümer der betreffenden Konfigurationsdatei, die Freigabe löschen, umbenennen oder die Freigabe-Optionen ändern kann. Über die Rechte des freigegebenen Verzeichnisses selbst sagt dies direkt nichts aus. Diese dürfen ja offiziell über die UNIX-Extensions geändert werden. Aber meines Wissens eben nur so, und Root-Rechte können auch über die Extensions nicht von einem gewöhnlichen User geändert werden.

Das Tool net usershare bzw. der Dateimanager ändert ja nach Rückfrage beim Erstellen einer Persönlichen Freigabe den Modus (chmod…) bei Bedarf, z.B. für den Gast-Zugang. Doch dies betrifft AFAIK nur den Modus und nicht den Eigentümer, und es geschieht auch gleich und nicht erst bei einem Zugriff eines Client. Doch dies und die UNIX-Extensions zeigen, dass Samba sehr wohl an den Dateirechten herummacht. In Samba-4 kann man ja sogar von einem Windows-Client aus ACLs bei den Freigaben auf einem Samba-Server (Linux) setzen! Es kann also schon sein, dass das GVFS hier ein legales Feature zu Unrecht benutzt. Ins Unreine gedacht: Das GVFS könnte sich z.B. selbst vielleicht transparent mit Root-Rechten der UNIX-Extensions bedienen, ohne diese als Option den Usern zur Verfügung zu stellen (??).

Bevor ich mich in der Lage sehe, hier einen einigermaßen qualifizierten Bug-Report zu verfassen, muss ich noch ein bisschen herumspielen. Und ich wäre sehr froh, wenn dabei noch ein paar Andere mitmachen würden. Wichtig wären z.B. noch folgende Fragen:

• Wie sieht es in KDE beim Zugriff über ein KIO-Slave aus?

• Ändert sich etwas, wenn auf dem Server die UNIX Extensions generell deaktiviert werden (unix extensions = no)?

• Was geschieht, wenn man die Einschränkung, dass man Usershares nur für eigene Ordner und Dateien erstellen darf, durch eine Änderung in der sm.conf aufhebt (usershare owner only = no)?

• Was geschieht, wenn man als anderer Benutzer (also nicht als derjenige User, der die Freigabe erstellt hat) auf die Datei zugreift und diese verändert (die Optiom usershare allow others = yes in der smb.conf macht dies möglich)?

• Man kann in der smb.conf eine Dummy-Freigabe als allgemeines Template für Usershares einrichten. Lässt sich damit das beschriebene Verhalten beeinflussen?

Fragen über Fragen.

@Max-Ulrich_Faber

Erst mal vielen vielen Dank für dein Mühen, das ist gerade Seelenbalsam für mich, da meine Mitstudenten dies schlicht nicht interessiert.

Ich werde morgen (sitze gerade in Java und IT Forensik dran), das ganze mit deinen Vorschlägen testen und einfach mal eine Distro mit KDE probieren (openSuSE), sowie CentOS als Server nochmal nutzen.

Zu deinem Bedenken, wer verantwortlich ist für den Bug...nun, ich bin aktuell der Meinung, das hier beide den Bug Report benötigen...es ist nicht auszuschließen das beide buggy sind. Besser 2 Teams daran arbeiten lassen, als ein falsches.

Was ich zusätzlich noch testen will:

• Excel Tabelle die User 1 gehört und sonst niemand editieren darf, es mit User 2 probieren. Das gleiche auch für eine PDF. Damit will ich nur verdeutlichen, wie gravierend es ist, wenn "vertrauliche" Dateien

von anderen geöffnet werden.

• Das ganze via einer SSH Verbindung....

• Physisch auf meinen Latop Host und Physisch auf meinen Hauptrechner, also die VM's mal sein lassen. Mag jetzt unnütze sein, doch ich will einfach alles ausschließen können.

… da meine Mitstudenten dies schlicht nicht interessiert.

Was studiert Ihr denn?

Besser 2 Teams daran arbeiten lassen, als ein falsches.

Die Erfahrung lehrt leider, dass die einander dann gerne den Schwarzen Peter zuschieben, und dass dann gar nichts passiert ☹

Excel Tabelle die User 1 gehört und sonst niemand editieren darf, es mit User 2 probieren.

Da musst Du dann wohl LibreOffice o.ä. nehmen, denn Excel läuft ja ohne Wine auf einem Linux-Server nicht. Und Wine lassen wir da 'mal lieber außen vor.

Das ganze via einer SSH Verbindung....

Ich hoffe doch sehr, dass es da keine Probleme gibt. Das wäre noch viel schlimmer, denn da käme man wirklich auf das gesamte System.

also die VM's mal sein lassen

Ich kann mir nicht vorstellen, dass die VMs da etwas ändern. Bring jetzt nur nicht deshalb Deinen Hauptrechner durcheinander!

Was studiert Ihr denn?

Informatik mit dem Schwerpunkt IT Sicherheit.

Informatik mit dem Schwerpunkt IT Sicherheit.

Und dann finden Deine Mitstudenten dies "schlicht nicht interessant"? Sehr seltsam…

Hab leider nichts positives zu berichten.

Unter openSuSE tumbleweed griff ich auf einen Test Ordner mittels Samba zu (Server-->Ubuntu), rein über den KDE Dateimanager...und...genau das gleiche Problem. Andersherum, also SuSE als Server und Ubuntu als Client brachte auch keine Erfolge. Der mount über die Konsole (egal welche Distro nun als Server fungiert), klappt einwandfrei...sprich, Rechte bleiben genau so wie sie sein müssen!

Das ist ein Desaster, wenn Samba fällt....fällt Linux!

NetworkWarrior schrieb:

Das ist ein Desaster, wenn Samba fällt....fällt Linux!

Das halte ich für eine gewagte Aussage. Ich habe noch nie Samba gebraucht bei meinen Pinguinen.

Aus dem Grund weiß ich auch aktuell nicht, wie ich euch helfen kann. Falls ihr also etwas von einem Nicht-Sambanesen an Hilfe brauchen könnt, sagt Bescheid.

Das halte ich für eine gewagte Aussage. Ich habe noch nie Samba gebraucht bei meinen Pinguinen.

Samba ist schon eine Instanz.

Wenn ich mir das Schmieren-Theater mit Limux angucke, das absolute Desinteresse an Linux von so ziemlich jedem, mit dem ich hier Kontakt hab, bis hin zu all den zahlreichen Intrigen, Fake-News und sonstigen Bullshit den ich stetig lesen und hören muss bezüglich Linux. Hab gerade 2 VM's mit Windows Server am laufen...muss da bald eine Zertifizierung ablegen (Buch mit ca 1000 Seiten hab ich heute Abend durch, andere dumpen nur)...Windows Server ist nett, das war es dann auch. PowerShell ein gewürge veglichen zur Bash und so ziemlich alles ist irgendwie Rückständig. Lediglich die GPOs mit AD halte ich für richtig gut und an sich das ein zigste was einen Windows Server rechtfertigen kann...ok, werde gerade offtopic

Das ist ein Desaster, wenn Samba fällt....fällt Linux!

Der Satz reizt zum Widerspruch!

Ich finde auch, dass Samba wichtig ist. Doch hier geht es um ein Problem, das eindeutig mit Desktop-Linux bzw. mit graphischen Oberflächen zu tun hat. Die sind nicht das Wesentliche an Linux. Im Vergleich zur Linux Serversoftware ist Desktop-Linux (auch Ubuntu…) eher marginal.

Ich würde außerdem noch nicht sagen, dass Samba fällt, wenn der Zugriff aus einer GUI auf Persönliche Freigaben, die mit net usershare erstellt sind, fehlerhaft ist. Das ist schlimm, kein Zweifel, aber es ist noch kein GAU. Man kann diese Sicherheitslücke leicht umschiffen, und niemand ist darauf angewiesen, die problematische Kombination zu verwenden. Sicher, man verliert schon Vertrauen in das "absolut sichere Linux". Doch niemand ist perfekt, und auch Linux ist eben nicht absolut sicher. Niemand Vernünftiges hat dies auch jemals behauptet.

Ich habe die ewige Vergleicherei mit Windows und auch die gegenseitigen Beschimpfungen satt. Jedes System hat seine Schwächen, und ich verwende eben lieber Linux, weil es meiner Ansicht nach klarer und logischer strukturiert und deshalb für mich durchsichtiger ist. Man darf wohl persönliche Vorlieben haben ohne immer betonen zu müssen, wie schlecht und dumm die Andern sind.

Ich finde diesen Fehler schon wichtig, und wir sollten uns bemühen, dass er möglichst bald beseitigt wird. Doch das Kind mit dem Bade ausschütten sollten wir deshalb auch nicht.

ok, werde gerade offtopic

Ja.

Hallo,

was mir in all den seitenlangen Diskussionen fehlt ist die Frage, ob den jetzt eigentlich das Sticky-Bit in dem freigegebenem Ordner gesetzt ist oder nicht!

Ohne würde ich euch den Bug eher niedrig einstufen. Wenn das mit gesetztem Sticky geht, wäre das schon ein größeres Problem (auch wenn ich von Samba nicht so viel Ahnung habe).

Also: Habt ihr das Sticky-Bit im freigegebenem Ordner und allen Unterordnern gesetzt?

Ansonsten habt ihr das Recht zum Überschreiben eben standardmäßig gewährt.

Viele Grüße

Vej

Also: Habt ihr das Sticky-Bit im freigegebenem Ordner und allen Unterordnern gesetzt?

Sehr gute Frage! Danke!

Bisher war das Sticky Bit nicht gesetzt gewesen. Doch auch ohne Sticky Bit darf ja ein gewöhnlicher Nutzer Dateien, auf denen nur Root Schreibrechte hat, nicht verändern. Und das Ändern des Eigentümers ohne Root-Rechte geht schon gar nicht. Das Recht zum Überschreiben ist also zwar schon standardmäßig gewährt, aber eben nicht so. Deshalb geht es ja mit dem cifs-vfs und über smbclient so nicht.

Ich habe nun 'mal für die Freigabe das Sticky-Bit gesetzt. Leider ändert dies überhaupt nichts. Auch das Sticky Bit word offenbar vom GVFS/smb einfach ignoriert. Das ist schon sehr schlimm.

Zum Glück ist ja der "professionelle" Weg nicht das GVFS, sondern cifs-vfs oder smbclient. Und diese arbeiten ja offenbar korrekt. Aber in "Jedermann-Distros" wie z.B. Ubuntu wird halt bevorzugt über die GUI bzw. den Dateimanager das GVFS verwendet. Weil der Fehler offenbar auch im KIO-Slave in Kubuntu auftritt, steckt er wahrscheinlich etwas tiefer. Doch offenbar nicht so tief, dass das gesamte Samba damit ins Wanken gerät. 😕

Ins Unreine gedacht: Da das Problem nach Erkundungen von NetworkWarrior offenbar auch im KIO-Slave auftritt, könnte es dann vielleicht daran liegen, dass das GVFS und der KIO-Slave die Freigaben im Userspace einbinden? Dann wäre es vielleicht sogar ein allgemeines Problem von Fuse?

Gruß – Max-Ulrich

Hallo Max-Ulrich_Farber.

Max-Ulrich_Farber schrieb:

Bisher war das Sticky Bit nicht gesetzt gewesen. Doch auch ohne Sticky Bit darf ja ein gewöhnlicher Nutzer Dateien, auf denen nur Root Schreibrechte hat, nicht verändern. Und das Ändern des Eigentümers ohne Root-Rechte geht schon gar nicht.

Naja, wenn ich eine Datei mit identischem Inhalt überschreibe gehört sie mir. Wenn ich euch richtig verstehe, kann man mit dieser Lücke ja auch nicht beliebige Nutzer zu Dateibesitzern machen, sondern "nur" den Nutzer des Sambashares.

Ich habe nun 'mal für die Freigabe das Sticky-Bit gesetzt. Leider ändert dies überhaupt nichts. Auch das Sticky Bit word offenbar vom GVFS/smb einfach ignoriert. Das ist schon sehr schlimm.

Mh, ja das ist dann wirklich sehr ungünstig. Schreibt das also am besten mit in den Bugreport.

Viele Grüße

Vej

Naja, wenn ich eine Datei mit identischem Inhalt überschreibe gehört sie mir

Falls ich das überhaupt darf. Doch eine Datei mit Eigentümer root:root und Modus 0664 darf ich als gewöhnlicher Benutzer eben gar nicht überschreiben!

Wenn ich euch richtig verstehe, kann man mit dieser Lücke ja auch nicht beliebige Nutzer zu Dateibesitzern machen, sondern "nur" den Nutzer des Sambashares.

Eben $USER:$USER. Bei usershare allow others = yes dürften das wohl ziemlich viele sein (?) …

Mh, ja das ist dann wirklich sehr ungünstig

sehr gelinde ausgedrückt!

Gruß – Max-Ulrich

Moin.

Mal eine Nachfrage: was muss ich denn einstellen, um das Verhalten nachzuvollziehen?

Die Samba Config aus dem Eingangspost hat doch keine persönlichen Freigaben via net usershare, oder habe ich das übersehen?

Voraussetzung sind doch

• Samba Server: Freigabe mit net usershare erstellen; in dieser Freigabe eine Datei mit Dateieigentümer root anlegen bzw ablegen, dabei können Others diese Datei nur lesen

• beliebiger Linux Client: Samba Shares (net usershares) mit GVSF einbinden und die root Datei öffnen, anschließend ändert sich die Dateieigentümerschaft auf den User

Geht das nur mit root Dateien auf dem Server oder ist das bei allen Dateien auch der Fall?

Muss der Client in einer bestimmten Gruppe (adm?) sein oder ist das egal (Gastaccount)?

Auf meiner Diskstation von Synology ist zwar Samba vorhanden, es fehlen aber die net Utilities. Von daher geht der Bug wohl hier nicht zum Nachspielen.

Auf meiner Diskstation von Synology ist zwar Samba vorhanden, es fehlen aber die net Utilities. Von daher geht der Bug wohl hier nicht zum Nachspielen.

Ja, mit dem Synology-NAS als Server geht das nicht. Du musst einen gewöhnlichen Linux-Rechner als Server verwenden ("net usershare: usershares are currently disabled") Du kannst aber jeden Linux-Rechner mit installiertem Samba als Server benutzen und sogar den gleichen Rechner auch als Client, also sozusagen übers Netzwerk auf die eigenen Freigaben zugreifen.

anschließend ändert sich die Dateieigentümerschaft auf den User

Erst beim Zurückschreiben (speichern) der geänderten Datei.

Geht das nur mit root Dateien auf dem Server oder ist das bei allen Dateien auch der Fall?

Soviel ich sehe bei allen.

Muss der Client in einer bestimmten Gruppe (adm?) sein oder ist das egal (Gastaccount)?

Bestimmte Gruppe nein; Gast-Zugang habe ich noch nicht getestet.

Die Samba Config aus dem Eingangspost hat doch keine persönlichen Freigaben via net usershare, oder habe ich das übersehen?

Persönliche Freigaben erscheinen nicht in der smb.conf (siehe dazu z.B. Samba Server GNOME)

EDIT: Könnte vielleicht 'mal jemand auch FuseSMB 🇬🇧 oder SmbNetFS testen, ob der Fehler vielleicht bei FUSE liegt?