staging.inyokaproject.org

Max-Ulrich_Farber schrieb:

Fehler gemeldet: GVFS violating UNIX permissions inside Samba shares

Danke! Ich hab mal auf "affects me" geklickt, auch wenn ich kein Samba nutze ☺

NetworkWarrior schrieb (s.o.):

über den KDE Dateimanager...und...genau das gleiche Problem.

Es wäre hilfreich, wenn er dies im Bug-Report anfügen würde. Ich konnte dies leider nicht selbst testen.

Hallo,

vielen Dank für den Bugreport.

Dem ganzen fehlt aber leider eine klare Reproduktionsanleitung, die die folgende Frage beantworten sollte:

Was muss ich minimal machen um das nachzustellen?

Könnte da jemand, der das nachstellen kann etwas zu verfassen.? Also etwa so (ich habe leider nicht so viel Ahnung von Samba, also das bitte an die Gegebenheiten anpassen):

1. Install samba version 4.3.11-Ubuntu on an Ubuntu XYZ using the standard configuration from samba_configuration.txt

2. Create a share using the configuration share_configuration.txt

3. Add a skript test.bash inside of this share, give it the permissions 774 and change owner and group to root

4. Connect to this share using nautilus XYZ on Ubuntu XYZ

5. Open test.bash from the client using a file editor like gedit

6. Append echo "I am evil" to test.bash

7. Save test.bash in that file editor

Expected Result: The file editor should complain about insufficient rights and the skript on the server remains unchanged.

Result: The file is saved. The server contains the changed script owned by the samba user with permissions XYZ.

Dann natürlich die Konfigurationsdateien samba_configuration.txt und share_configuration.txt anhängen.

Hintergrund für diese detaillierte Beschreibungen ist, das später Leute vom SRU (Stable Release Update) Team und den Sponsors (zuständig für das Hochladen des Fixes) diesen Fehler nachbauen müssen, ohne das diese unbedingt Samba verwenden und kennen.

Ich hoffe diese Tipps eines Bugtriagers (zuständig für das verbessern von Bugreports und das setzen von Wichtigkeiten) helfen euch das schnell behoben zu bekommen.

Viel Erfolg

Vej

…diesen Fehler nachbauen müssen, ohne das diese unbedingt Samba verwenden und kennen.

Wenn davon auszugehen ist, dass die Leute, die den Fehler nachbauen, Samba gar nicht kennen, dann müsste man noch weiter ausholen. Nach der Installation von Samba müsste auf dem Server für (mindestens) einen Benutzer ein Samba-Account mit Benutzername und Passwort angelegt werden. Mit dieser Kombination von Samba-Benutzername und Passwort müsste man nun vom Client aus die Verbindung herstellen usw.

Es ist schwierig und sehr umfangreich, den ganzen Vorgang lückenlos für jemand zu beschreiben, der Samba gar nicht kennt. Doch das Handling von Samba-Shares ist ja ein wichtiger Bestandteil des GVFS. Deshalb dachte ich, man kann wohl annehmen, dass jemand, der sich mit Fehlern im GVFS befasst, die Grundlagen von Samba kennt.

I'll try to do my best anyhow, but no more today.

Gruß – Max-Ulrich

Nochmal meine Bitte, vor allem an den Threadstarter NetworkWarrior:

Wenn der Fehler auch beim KIO-Slave auftritt, so sollte dies unbedingt bei der Fehlermeldung vermerkt werden, denn dies hilft bei der Lokalisierung des Fehlers. Ich glaube ja schon, was NetworkWarrior dazu geschrieben hat. Doch ich kann es selbst leider nicht überprüfen, und ich schreibe nichts in einen Bugreport, was ich nicht selbst verifiziert habe.

Was die von Vej gewünschte ausführliche Nachbau-Anleitung angeht, so kümmere ich mich darum, sobald ich dafür Zeit habe.

Gruß – Max-Ulrich

Ja, die Nachbauanleitung wäre wirklich hilfreich. Ich hab's versucht gerade nachzustellen und bin leider gescheitert.

Server (Ubuntu 16.04; 192.168.10.158)

• smb.conf (einzige Ergänzung)

### Test

[Samba_Test]
path = /opt/samba_test
writeable = yes

• share /opt/samba_test mit folgenden Rechten

drwxr-xr-x 1 root root   4,0K Feb 18 13:28 samba_test

• share /opt/samba_test/ mit folgenden Dateien / Rechten:

-rwxrwxr-- 1 root root    0 Feb 18 13:28 test_root
-rw-r--r-- 1 root root    0 Feb 18 13:53 test_root2

• Samba-Benutzer: samba_test

Client (Debian stretch)

• gvfs Version 1.30.3

• Einbinden des Shares

gvfs-mount smb://192.168.10.158/Samba_Test

• Eigenschaften der Freigabe (auf meinen Benutzer gemappte Rechte)

-rwx------ 1 $USER $GROUP   0 Feb 18 13:57 test_root
-rwx------ 1 $USER $GROUP   0 Feb 18 13:53 test_root2

• Demnach hätte ich zwar benutzerbezogene Rechte, aber die Rechte wirken eben nicht (Vererbung der lesenden Share-Rechte vom Samaba-Server passt):

mv test_root test_root_3
mv: das Verschieben von 'test_root' nach 'test_root_3' ist nicht möglich: Keine Berechtigung

Edit:

Es klappt bei mir nur, wenn auf dem Share /opt/samba_test zuvor eine 777 Permission gegeben wurde. Allerdings tritt das Verhalten bei mir nicht mehr auf, wenn das Sticky Bit auf dem Share gesetzt wird. Also:

drwxrwxrwxt 1 root root   4,0K Feb 18 20:20 samba_test

@Hans9876543210:

Jetzt muss ich ganz genau durchlesen, was Du gemacht hast. Doch ich glaube, dass da ein Missverständnis drin ist:

• Die Rechte werden vom GVFS korrekt beachtet, wenn sie sich auf die gesamte Share beziehen. Wenn also die z.B. Share root:root gehört mit Modus 0755 oder weniger, dann kannst Du als gewöhnlicher Benutzer darauf nicht schreiben, egal, wie die Samba-Berechtigungen festgelegt sind. Dies ist so auch in Ordnung.

• Doch wenn sich innerhalb einer Share, auf die Du vollen Zugriff hast, eine Datei befinder, in die Du nach deren Rechten eigentlich nicht schreiben dürftest, dann geht dies über das GVFS trotzdem. Und das dürfte nicht der Fall sein. Über cifs-vfs oder SmbNetFS geht es hingegen nicht, so wie es auch sein sollte.

So wie ich sehe, hast Du immer mit den Rechten für die gesamte Share experimentiert. Mach 'mal folgendes:

1. Lege einen Ordner ~/Test an mit Eigentümer $USER:$USER und Modus 0755 oder mehr.

2. Lege innsehalb desselben eine Datei ~/Test/test1 an mit Eigentümer root:root und Modus 0644. In diese dürfte also nur Root schreiben können.

3. Gib den Ordner ~/Test via Samba als [TestShare] frei, sodass $USER darauf zugreifen darf, z.B. mit

   [TestShare]
   path = /home/$USER/Test
   writeable = yes

   oder wahlweise auch als "Persönliche Freigabe" mittels net usershare.

4. Greife nun von einem Linux-Client aus über das GVFS als $USER auf die Share TestShare zu und editiere die darin befindliche Datei test1 z.B. mit gedit oder pluma.
   Du kannst nun diese Datei verändern und wieder abspeichern, obwohl eigentlich nur Root dies dürfte.

5. Gib nun auf dem Server ein ls -la ~/Test. Du siehst, dass die Datei ~/Test/test1 jetzt $USER:$USER gehört und nicht mehr root:root. (geklaut … 😢 ).

Das war's. Und sowas dürfte nicht gehen!!

Moin.

Also mein Test-Share hatte als Eigentümer / Gruppe root:root und die Rechte waren 777, sodass es hätte klappen sollen.

Die beiden Demodateien hatten auch entsprechende Rechte (siehe oben), ein Abspeichern war aber nicht möglich. Ich mach es nachher noch mal ganz genau nach deiner Anleitung.

Edit:

Auch nach deiner Anleitung kann ich es nicht nachstellen.

Auch nach deiner Anleitung kann ich es nicht nachstellen.

Das ist interessant. Um ganz sicher zu sein, habe ich den Vorgang nochmal Schritt für Schritt genau nach der Anleitung ausgeführt. Sogar von einem Xubuntu-Client aus mit dem Dateimanager Thunar und dem Editor Mousepad, um ganz sicher zu gehen, dass der Fehler nicht etwa bei Nautilus und gedit liegt (was ich aber nie wirklich geglaubt hatte). Alles lief genau so ab wie oben beschrieben. Die Textdatei test1 wurde von $USER editiert, geändert und geklaut.

Jetzt müsste man wissen, was wir verschieden machen. Denn irgend etwas muss ja verschieden sein.

Das GVFS ist ja ein vielfältiger Apparat, über den man auch auf lokale Dateien zugreifen kann. Damit wir uns nicht falsch verstehen: Der Fehler tritt nicht bei einem lokalen Zugriff auf, sondern ausschließlich beim Zugriff mittels Samba von einem Linux-Client aus. Ob dies bei allen Samba- und GVFS-Versionen der Fall ist, weiß ich natürlich nicht. Meine Versionen stehen jedenfalls im Fehlerbericht:

Ubuntu 16.04
Samba Version 4.3.11-Ubuntu (server and client)
gvfs 1.28.2 (client)

Hallo

Vielleicht wäre es hilfreich mit der aktuellsten Version zu testen.

aktuelle Samba Version 4.5.5 aktuelle gvfs Version 1.31.90 https://download.gnome.org/sources/gvfs/1.31/

Gruß cflinux

Ich habe mich an die aktuelle LTS-Version von Ubuntu gehalten (16.04 LTS). Denn die muss ja erst 'mal sicher funktionieren.

Zur Sicherheit habe ich gerade noch ein dist-upgrade durchgeführt. Die von mir genannten Versionen sind in Ubuntu 16.04 LTS nach wie vor aktuell.

Max-Ulrich_Farber schrieb:

Jetzt müsste man wissen, was wir verschieden machen. Denn irgend etwas muss ja verschieden sein.

Server (Samba: 4.3.11) :

$ mkdir ~/Freigabe_Test #Ordner beim Benutzer samba_test erstellen

$ ls -hal F*
Freigabe_Test:
insgesamt 8,0K
drwxrwxr-x  2 samba_test samba_test 4,0K Feb 20 13:50 .
drwxr-xr-x 16 samba_test samba_test 4,0K Feb 20 13:50 ..

$ chmod 0755 Freigabe_Test

$ ls -hal F*
Freigabe_Test:
insgesamt 8,0K
drwxr-xr-x  2 samba_test samba_test 4,0K Feb 20 13:50 .
drwxr-xr-x 16 samba_test samba_test 4,0K Feb 20 13:51 ..

$ sudo touch /home/samba_test/Freigabe_Test/roottest

$ sudo chmod 0644 /home/samba_test/Freigabe_Test/roottest

$ ls -hal Freigabe_Test/*
-rw-r--r-- 1 root       root          0 Feb 20 13:52 Freigabe_Test/roottest

Client (eingebunden via Thunar, Debian Stretch, kein Samba, sondern nur gvfs in der Version 1.30.3)

$ mount
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

$ cd /run/user/1000/gvfs/smb-share\:server\=test_samba\,share\=freigabe_test/

$ ls -hal
insgesamt 2,0K
drwx------ 1 $USER $USERGROUP    0 Feb 20 13:54 .
dr-x------ 3 $USER $USERGROUP    0 Feb 20 13:33 ..
-rwx------ 1 $USER $USERGROUP    0 Feb 20 13:52 roottest

$ echo "test" > roottest 
bash: roottest: Keine Berechtigung

Also das funktioniert genau so, wie ich es erwartet hätte. Schreibzugriff geht nicht. Unter Lubuntu 16.04 (gvfs 1.28.2) ist die Änderung auch nicht möglich.

Nachtrag:

Soweit ich das sehe, kann ich jeweils nur dann eine Änderung erzielen, wenn folgende Konstellation vorliegt.

• beim Client mit der Kennung "samba_test" anmelden (sprich: mit dem Benutzer, dem das Share-Verzeichnis gehört)

• da der Share im persönlichen home von samba_test liegt, kann ich - unabhängig der angezeigten Zugriffsrechte - einen Zugriff vornehmen, auch wenn man keine Rechte diesbezüglich haben sollte

Edit: Das könnte dann natürlich der Bug sein. Scheinbar hat das aber was mit dem Eigentümer des Shares zu tun. Das passt aber wiederum nicht zum Anfangspost, da der Eigentümer ja root war und nicht ein beliebiger Benutzer. Ein direkter Zugriff von root ist ja nicht erkennbar.

Auf meinen vServer hatte ich den Benutzer samba_test angelegt; auf meinem Client einen anderen Benutzer. Daran kann es imho aber nicht liegen.

Edit 2: Bei Gelegenheit werde ich das hier probieren. Also einen dedicated user für Samba anlegen und gar nicht mit root als Owner arbeiten.

-rwx------ 1 $USER $USERGROUP    0 Feb 20 13:52 roottest

Schreibzugriff geht nicht.

Wieso nicht? $USER darf in freigabe_test/roottest doch schreiben. Bei mir macht auch $ echo "test" > roottest keine Probleme. Und so sollte es eben nicht sein.– Bei Dir muss es wohl ein anderes Hindernis geben, warum Du nicht nach roottest schreiben kannst. Ist die Datei vielleicht irgendwo sonst noch geöffnet, sodass sie locked ist?

Du kannst aber auch einfach 'mal auf dem Client roottest z.B. mit gedit editieren, verändern und wieder abspeichern. Das geht, und nachher ist die Datei roottest auf dem Server verändert und Eigentum von $USER.

Doch probier' mal das Gleiche, indem Du Freigabe_Test/roottest mit mount -t cifs ..., also mit dem cifs-vfs einbindest. Da geht dies nicht. Und dies ist korrekt.

Der von Dir unter "Edit" aufgeführte Link betrifft etwas ganz Anderes. Da wird force user verwendet, um von Windows aus den Zugriff zu ermöglichen. Das ist normal. – Windows 7 (Win 10 habe ich nicht) verhält sich nebenbei bei obigem Problem korrekt: Dateien, in die auf dem Server nur Root schreiben darf, kann ein gewöhnlicher User vom Windows-Client aus nicht verändern oder überschreiben.

Nochmals die Versionen: Server: gleiche Samba-Version; Client: ich gvfs 1.28.2, Du gvfs 1.30.3
Sollte der Fehler vielleicht im GVFS 1.30 schon stillschweigend behoben sein? Das würde mich wundern. Muss ich dann vielleicht in den nächsten Tagen 'mal in einer VM ausprobieren.

Moin.

Ich hatte auch Lubuntu getestet, da ging es auch nicht. Also an der gvfs Version scheint es nicht zu liegen.

Ja, laut den Rechten hätte ich schreiben können. Tatsächlich ging der Zugriff aber nicht (Anzeige-Bug?). Weder per (grafischen) Editor noch via echo. Die Datei war auch nicht auf dem Server geöffnet (aber das werde ich sicherheitshalber nochmal prüfen). Wenn ich morgen Zeit habe, werde ich es noch mal ohne gvfs testen. Dann sollten ja tatsächlich nur die Lese-Rechte dargestellt sein und nicht alle rwx, richtig?

Vielleicht kann es ja noch ein Vierter nachstellen.

Ich hatte auch Lubuntu getestet, da ging es auch nicht

Welche Version? In 17.04 Beta ist ja jetzt GVFS 1.30.3 verbaut. Das ist die gleiche Version wie in Deinem Debian.

Doch wenn Du mit GVFS 1.28.2 nicht schreiben kannst, dann müsste der Unterschied zu meinem Beispiel eigentlich auf dem Server zu suchen sein. Komischerweise konnte ich bei meinem ersten Versuch ja auf einer Allgemeinen Freigabe auch nicht schreiben, nur auf Persönlichen Freigaben. Doch jetzt geht es bei beiden. Ich weiß auch nicht, was da los war. Ich habe den Fehler halt erst 'mal vor dem Bildschiem gesucht und gedacht, dass ich wohl irgend etwas übersehen habe. Kann ja auch sein …

Nochmal genau meine Konstellation: Der freigegebene Ordner ist in meinem Heimverzeichnis und gehört mir, und ich darf auch ganz legal auf diesen schreiben, mit oder ohne Samba. Nur die betreffende Datei innerhalb dieser Freigabe (eine reine Textdatei) gehört root:root mit Modus 0644.

Dann sollten ja tatsächlich nur die Lese-Rechte dargestellt sein und nicht alle rwx, richtig?

Das habe ich nicht untersucht. Ich kann jedenfalls nicht schreiben, das ist sicher. Es gibt aber, wie Dein Beispiel zeigt, wohl auch andere Möglichkeiten, das Schreiben zu verhindern. Nur ACL sind offenbar hier nicht im Spiel; ich habe jedenfalls keine gefunden.

EDIT:

Also, die GVFS-Version ist es nicht, die den Unterschied macht. Ich habe 'mal Ubuntu 17.04 Beta in einer VM installiert (GVFS 1.30.3), und von dort aus kann ich auch schreiben, und die Datei wird geklaut – genau wie bei GVFS 1.28.2.