staging.inyokaproject.org

Max-Ulrich_Farber schrieb:

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)

Ja, genau das meinte ich ja. NetworkWarrior hatte den testshare in der smb.conf und konnte trotzdem die Rechte ändern:

NetworkWarrior schrieb:

Im Pfad /srv/ ein Ordner "testshare" mit Rechten 777 angelegt. In der smb.conf folgende Einträge vorgenommen

1 2 3 4

[testshare] comment = Test-Freigabe (Zugriff von %u%I) path = /srv/testshare read only = No

Das spricht doch gegen eine persönliche Freigabe.

@ Max-Ulrich_Farber:

Da du es nachstellen kannst: Wäre es möglich, dass du in Samba mal den Loglevel zeitweise auf den höchstmöglichen Wert (log level = 3) setzt und dann das Samba-Logfile (/var/log/samba ?) nach Auffälligkeiten sichtest? Das müsste ja relativ überschaubar sein.

Hallo in die Runde.

Max-Ulrich_Farber schrieb:

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

Ich habe das gerade mal mit sshfs getestet (das ist ja auch FUSE). Da besteht diese Lücke nicht.

Da Hans9876543210, das nicht nachstellen konnte: Für eine guten Bugreport, der zügig bearbeitet wird, solltet ihr eine möglichst knappe aber vollständige Reproduktionsanleitung bereithalten.

Viele Grüße

Vej

Das spricht doch gegen eine persönliche Freigabe.

Ja. – Ich will's nochmal mit Allgemeinen Freigaben versuchen und dort noch ein bisschen mit Optionen herumspielen (guest ok, valid users, write list usw.) Ich habe da natürlich noch nicht alles gecheckt. Doch bisher trat bei mir der Fehler jedenfalls bei Allgemeinen Freigaben (noch?) nicht auf.

Ich habe das gerade mal mit sshfs getestet (das ist ja auch FUSE). Da besteht diese Lücke nicht.

Zum Glück nicht! Wie sieht es mit SSH über GVFS aus (sftp://...)? Ist hoffentlich auch ok.

EDIT:

Hans9876543210 hat Recht: Das Problem kann auch bei Allgemeinen, in smb.conf eingetragenen Freigaben auftreten. Wenn der Benutzer auf die Freigabe Schreibzugriff hat, dann hat er dies via GVFS/Samba auch auf alle darin enthaltenen Dateien, egal, wie deren Besitz- und Zugriffsrechte festgelegt sind. Und nach dem Schreibzugriff ist er dann mit seiner Hauptgruppe Besitzer dieser Dateien. Dies gilt für den Zugriff über das GVFS unabhängig davon, ob es sich um Persönliche oder Allgemeine Freigaben handelt. Ich hatte leider vorher bei der Allgemeinen Freigabe deren Rechte anders festgelegt. Sorry 😳

Das Samba-Tool net usershare ist wohl damit entlastet.

Mounte ich die Dateien mittels cifs-vfs, werden die Dateirechte der einzelnen Dateien immer korrekt beachtet, auch wenn die Dateirechte der gesamten Freigabe mehr erlauben würden. Dies gilt unabhängig davon, ob die UNIX-Extensions aktiv sind oder nicht. Nur beim Zugriff über das GVFS bzw. den KIO-Slave haben offenbar alle zugreifenden Benutzer alle Rechte, die an sich nur Usern zustehen, die als admin user eingetragen sind. Das gilt so offenbar gleichermaßen für Allgemeine und für Persönliche Freigaben.

admin users (S)

    This is a list of users who will be granted administrative privileges on the share. This means that they will do all file operations as the super-user (root).
    You should use this option very carefully, as any user in this list will be able to do anything they like on the share, irrespective of file permissions.

Da die Festlegung, wer bei welcher Freigabe als admin user fungieren darf, dem Server und nicht dem Client zusteht, finde ich das Verhalten des GVFS unzulässig. Doch es beruhigt mich, dass der Samba-Server offenbar unschuldig ist. Das GVFS (bzw. der KIO-Slave) ist ja "nur" Teil einer graphischen Oberfläche …

Moin.

Den Edit habe ich erst jetzt gesehen. Könntest du das log level mal hoch setzen und dann den Zugriff via GVFS vornehmen?

Der Server muss ja den Zugriff loggen und die Rechteänderung quasi protokollieren.

Vej schrieb:

Ich habe das gerade mal mit sshfs getestet (das ist ja auch FUSE). Da besteht diese Lücke nicht.

Kann ich bestätigen. Auch mit einem Wirrwarr-Gemounte und aktiviertem allow_others kann ich root-Dateien nicht mal lesen bei entsprechenden Rechten. Lustigerweise wird sie mir als "Eigentum" angezeigt.

Testkandidaten: root und dms auf dem "Server", schiggn auf dem Klient.

Verwendete Optionen: -o allow_other -o idmap=user -o uid=1000 -o gid=1000

Datei Original als root mit touch angelegt:

-rw-------   1 root root      0 Feb 12 20:44 testdatei.nothing

Lokal im sshfs-Verzeichnis:

-rw-------  1 schiggn schiggn    0 12. Feb 20:44 testdatei.nothing

Rechte aufm Server auf 660 geändert bringt mir auch keinen (Lese-)Zugriff. Jegliches echo, cat, etc. bringt "keine Berechtigung".

Gruppentest: Dazu wurde der Eigentümer auf den Freigabebenutzer dms geändert: Original:

-rw-rw----   1 dms root      0 Feb 12 20:44 testdatei.nothing

Lokal im sshfs-Verzeichnis:

schiggn@x220[$]› echo lala > testdatei.nothing
schiggn@x220[$]›  ll testdatei.nothing 
-rw-rw---- 1 schiggn schiggn 5 12. Feb 20:49 testdatei.nothing

Im Original bleiben Besitzer und Gruppe gleich.

Ich wage daher zu behaupten, dass dieser FUSE-Teil unschuldig ist.

Das ist ein ziemliches Dickicht, denn bei Samba gibt es so viele verschiedene Optionen, dass man nie weiß, ob man jetzt alles Wichtige durchprobiert hat. ☹

Für mich stellt sich die Situation nun so dar:

• Bei Samba-Freigaben gibt es die Option admin users = xyz (einzelne) bzw. admin users = &uvw (Gruppe). Alle diese Benutzer dürfen innerhalb der Freigabe auf alle Unterordner und Dateien voll zugreifen ohne Berücksichtigung der einzelnen Dateirechte (ähnlich wie beim SUID-Bit). Nach einem Schreibzugriff sind die Dateien dann Eigentum des zugreifenden Benutzers und seiner Hauptgruppe (s.o.). Von dieser Option sollte man verständlicherweise nur sehr restriktiv Gebrauch machen!

• Beim Zugriff über das GVFS bzw. KIO-Slave verhalten sich nun offenbar alle zugreifenden Benutzer genau so, wie wenn für sie die Option admin users gesetzt wäre. Und dies ist offenbar ohne besondere Berechtigung von jedem Linux-Client aus möglich. Dies widerspricht aber eindeutig dem Prinzip, dass der Server entscheidet, wer als admin user zugreifen darf.

• Ich kenne leider keine Option, mit der man den Zugriff übers GVFS bzw. KIO-Slave unterbinden könnte. Doch mit der Option browseable = no kann man ihn zumindest sehr erschweren.

Könntest du das log level mal hoch setzen und dann den Zugriff via GVFS vornehmen?

Ich glaube nicht, dass dies viel bringen würde. Der Fehler konzentriert sich meines Erachtens jetzt auf die Tatsache, dass offenbar unberechtigtermaßen die Option admin users verwendet wird. Doch wenn ich Zeit habe, kann ich ja zur Sicherheit 'mal die Logfile untersuchen.

Ich wage daher zu behaupten, dass dieser FUSE-Teil unschuldig ist.

Zumindest muss noch Samba dazukommen. Mit anderen Diensten passiert offenbar nichts. Doch ganz entlastet ist FUSE damit noch nicht.

Nein, ich denke da ist ein Ansatz von nem Fehler. Ich mappe ja per uid/gid auf den User 1000. Es werden auch die root:root - Dateien gemappt, was an sich ja schon nicht ganz richtig ist. Ich hatte an sich erwartet, dass nur die Dateien des verwendeten Loginusers gemappt werden. Also dms→schiggn in dem obigen Beispiel.

Vielleicht basiert darauf der Samba-Fehler, da nicht mehr geprüft wird ob man die Datei eigentlich besitzen darf oder nicht.

Ja, was ChickenLipsRfun2eat schreibt, läuft doch auf genau das Gleiche hinaus:

Ich mappe ja per uid/gid auf den User 1000

Das Mapping geschieht immer, wenn die UNIX Extensions nicht aktiv sind. Denn die UID/GID werden ja nicht vom Server auf den Client übernommen.

da nicht mehr geprüft wird ob man die Datei eigentlich besitzen darf oder nicht

Und das ist eben legal bei einem admin user. Der darf immer. Andere nicht.

Ich hatte an sich erwartet, dass nur die Dateien des verwendeten Loginusers gemappt werden

So sollte es IMHO bei allen übrigen Usern sein.

Ich habe jetzt noch auf einer VM das Tool SmbNetFS installiert, das ebenfalls auf FUSE basiert. Damit konnte ich bislang den Fehler nicht reproduzieren. Die Dateirechte werden damit anscheinend korrekt respektiert, wie beim cifs-vfs, das kein FUSE verwendet. Das alte FuseSMB ist IMHO überholt und buggy (jedoch immer noch in den Repositories). Das lassen wir besser 'mal ganz außen vor.

EDIT:

Es ist anscheinend doch noch etwas komplizierter:

• Es werden grundsätzlich alle Inhalte der Share gemappt, auf die irgendwie zugegriffen werden darf, ungeachtet der Rechte auf dem Server. Beim GVFS auf $USER:$USER, bei SmbNetFS kann ich mit den Optionen uid,gid angeben, auf welche Kombination von User und Gruppe.

• Bei SmbNetFS kann ich auch noch mit umask die Zugriffsrechte festlegen, beim GVFS sind sie anscheinend standardmäßig 0600. Die so vereinbarten Besitz- und Zugriffsrechte werden auf dem Client mittels ls -la ... korrekt angezeigt, bei SmbNetFS auch im Dateimanager, beim GVFS jedoch dort nicht ("Rechte konnten nicht ermittelt werden"). Diese Rechte stimmen u.U. nicht mit den Rechten auf dem Server überein.

• Bei der Rückübertragung einer veränderten Datei auf den Server weigert sich aber SmbNetFS, falls dies nach den Dateirechten des Servers nicht zulässig ist. Das GVFS tut dies offenbar nicht.

Damit verhält sich SmbNetFS anscheinend trotz FUSE genau so wie sich das cifs-vfs bei deaktivierten UNIX-Extensions verhält. Dasselbe sollte man auch vom GVFS erwarten.

Moin.

Ich finde das Thema sehr interessant und hoffentlich finden wir die Ursache. Die Option admin users kann evtl. eine Sackgasse sein, da:

Diese Option bezeichnet eine Reihe von Usern, die Dateioperationen ausführen, wie wenn sie root wären. Das bedeutet, dass sie die Arbeit jedes anderen Users verändern oder zerstören können, egal welche Rechte vorliegen. Alle von ihnen erzeugten Dateien haben Root als Eigentümer und verwenden die vorgegebene Gruppe der Admin-User. Die Option admin users wird gebraucht, um PC-Usern zu erlauben, als Administrator für einzelne Shares zu agieren. Wir raten dir dringend, diese Option zu vermeiden.

siehe hier.

Demnach dürfte die Dateieigentümerschaft nicht auf $USER wechseln, sondern bei root bleiben.

hoffentlich finden wir die Ursache

Das ist viel verlangt. Medizinisch gesprochen: Wir brauchen erst 'mal einen klar umrissenen Befund. Daran arbeiten wir immer noch. Bei der Diagnose sind dann wohl andere, vor allem die Entwickler, gefragt.

Die Option admin users kann evtl. eine Sackgasse sein, da: …

Scheint so zu sein. Ich habe jetzt ein bisschen mit admin users experimentiert. War die Datei vorher Eigentum von root:root, so wird sie nach einer Veränderung durch $USER, der als admin user eingetragen ist, nicht etwa Eigentum von $USER:$USER, sondern statt dessen Eigentum von root:$USER. Das heißt, ein admin user arbeitet zwar als "Root", behält dabei aber offensichtlich seine eigene Hauptgruppe bei. – Wieder etwas gelernt!

Interessant ist, dass es jetzt bei einem admin user im GVFS und im cifs-vfs genau gleich funktioniert.

Dass die Datei nach der Bearbeitung durch einen gewöhnlichen (d.h. nicht admin) User Eigentum von $USER:$USER wird, ist nicht verwunderlich. Verwunderlich ist eben, dass $USER die Datei überhaupt bearbeiten darf, obwohl die Dateirechte dies verbieten. Alles Übrige sind dann unliebsame und gefährliche Konsequenzen hiervon.

Vielleicht kann man es jetzt so formulieren: Beim Zugriff über das GVFS wird zwar nicht jeder Benutzer zum admin user, doch er bekommt Zugriffsrechte, wie sie nur einem admin user zustehen würden. Deshalb kann er auch genau so großen Schaden anrichten. Stimmt das so?

Ich würde jetzt gerne den Bug-Report fertigmachen. Dazu wäre es aber gut, wenn ich noch etwas mehr und genauere Informationen über das Verhalten unter KDE (Kubuntu) hätte. Damit könnte man dann auch leichter herausfinden, in welchem Layer die Rechteverletzung passiert. Denn in KDE gibt es ja kein GVFS. Und FUSE scheint wohl auch nicht verantwortlich zu sein.

Moin.

Könntest du nicht mal ein Minimalbeispiel deiner Config samt verwendeter Samba Version posten, damit man das nachstellen kann?

Das müsste man im Zuge des Bugreports ohnehin ☺

Im Log war nichts auffälliges, oder?

Ich glaube nicht, dass es ein Fehler von Samba ist. Sonst würde er auch mit cifs-vfs usw. auf dem Client auftreten.

Könntest du nicht mal ein Minimalbeispiel deiner Config samt verwendeter Samba Version posten, damit man das nachstellen kann?

Das problem tritt auch bei völlig unveränderter Standard-smb.conf auf (in einer VM ausprobiert). Die Freigaben können ganz normal als Allgemeine Freigaben oder auch mittels net usershare bzw. Dateimanager (Nautilus, Caja) erstellt sein. Also mit Sicherheit kein Fehler in den Einstellungen oder Optionen. Die smb.conf zu posten ist deshalb wohl überflüssig.

Samba: Version 4.3.11-Ubuntu (Server und Client)
GVFS: gvfs 1.28.2 (Client)

Hallo Max-Ulrich_Farber.

Max-Ulrich_Farber schrieb:

Das problem tritt auch bei völlig unveränderter Standard-smb.conf auf (in einer VM ausprobiert). Die Freigaben können ganz normal als Allgemeine Freigaben oder auch mittels net usershare bzw. Dateimanager (Nautilus, Caja) erstellt sein. Also mit Sicherheit kein Fehler in den Einstellungen oder Optionen. Die smb.conf zu posten ist deshalb wohl überflüssig.

Ich glaube nicht, das man deinen Bugreport als vollständig ansehen wird, ohne diese Konfigurationsdatei zu fordern. Also lade das besser mit hoch auch wenn es die Standardkonfiguration ist.

Viele Grüße

Vej

Fehler gemeldet: GVFS violating UNIX permissions inside Samba shares