staging.inyokaproject.org

Max-Ulrich_Farber schrieb:

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.

Mit Lubuntu 16.04 (also gvfs 1.28.2).

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.

Ja, ich habe es exakt so eingestellt. Ich kann definitiv nicht schreiben. Egal ob grafisch oder über das Terminal. Egal ob in Debian oder in Lubuntu 16.04. Auch wenn die Rechte eigentlich den Schreibzugriff ermöglichen sollten:

Max-Ulrich_Farber schrieb:

-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?

Die Datei ist definitiv nicht gelockt. Aus meiner Sicht ist das ein Anzeigefehler in gvfs. Offensichtlich hätte ich zwar schreibende Rechte, aber es geht nicht.

Max-Ulrich_Farber schrieb:

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.

Ja, das stimmt. Die Rechte und der Dateieigentümer sind absolut identisch zu denen auf dem Server.

Bei der verzweifelten Suche nach Unterschieden (unsere Sternzeichen wollen wir ja noch nicht vergleichen … 😀 ): Arbeitest Du mir 32- oder mit 64-Bit-Versionen?

Und (vielleicht) noch ein Unterschied: Hast Du $USER als Systemvariable angegeben oder den Usernamen in Klartext? Bei mir war es Klartext.

Ja, das stimmt. Die Rechte und der Dateieigentümer sind absolut identisch zu denen auf dem Server. (bei cifs-vfs)

Das sind die UNIX-Extensions. Doch auch bei deaktivierten Extensions (Server: unix extensions = no oder Mount-Option nounix auf dem client) kannst Du ohne Root-Rechte nicht schreiben, egal, was Du bei den Mount-Optionen als uid und file_mode eingibst. Und so sollte es auch sein.

Doch nun zurück zum GVFS. Ich habe mich jetzt 'mal mit dessen nächstem Verwandten, mit SMBNetFS befasst. Bei diesem wird – wie bei Dir im GVFS – die Datei als Eigentum von $USER:$USER mit -rw-r--r-- angezeigt. Trotzdem wird $USER der Schreibzugriff verweigert "keine Berechtigung". Wie dies intern gemacht wird, weiß ich nicht. Doch das Ergebnis ist jedenfalls korrekt. Offenbar bekommt der Client über Samba noch irgendwie mitgeteilt, wer auf dem Server welche Rechte hat, und das nicht nur für die Freigaben, sondern auch für einzelne Dateien innerhalb derselben. Um POSIX-ACL handelt es sich dabei jedenfalls nicht, wie getfacl roottest zeigt. Wie Samba das macht, weiß ich nicht.

Aus meiner Sicht ist das ein Anzeigefehler in gvfs

Die Anzeige stimmt wohl schon, aber das Schreibrecht beinhaltet eben nicht die Samba-Übertragung auf den Server. Die Datei erscheint auf dem Client nebenbei im Dateimanager nicht als schreibgeschützt, und im Editor kann man sie ganz normal editieren und verändern. Erst beim Versuch zu speichern kommt die Fehlermeldung.

Damit kristallisiert sich folgende Frage heraus: Warum erkennt das GVFS bei Dir dieses Samba-Schreibverbot, bei mir aber nicht? Denn mitgeteilt wird das Schreibverbot bei mir ja schon, sonst könnten SMBNetFS und das cifs-vfs es ja nicht beachten!

Ein kleiner Unterschied ist mir noch aufgefallen: Beim GVFS war die betreffende Datei als ausführbar (-rwx------ 1 $USER $USERGROUP ...) angezeigt, was sie auf dem Server aber nicht ist. Bei SMBNetFS jedoch nicht (-rw-r--r-- 1 $USER $USERGROUP ...).

Könntest Du bitte jetzt noch folgendes probieren:

• Blindversuch: Lege innerhaln der gleichen Share noch eine zweite Testdatei an, die aber nicht root:root gehört, auf die also $USER von den Rechten her schreiben dürfte. Kann denn $USER auf diese über GVFS/Samba vom Client aus schreiben?

• Bei mir sind samba_test und $USER identisch. Ist das bei Dir genau so? Wenn nicht, probier's mal so.

Max-Ulrich_Farber schrieb:

Bei der verzweifelten Suche nach Unterschieden (unsere Sternzeichen wollen wir ja noch nicht vergleichen … 😀 ): Arbeitest Du mir 32- oder mit 64-Bit-Versionen?

64-bit. Aber ich teste das alles mit diversen VMs ☺

Und (vielleicht) noch ein Unterschied: Hast Du $USER als Systemvariable angegeben oder den Usernamen in Klartext? Bei mir war es Klartext.

Das war Klartext, habs nur für das Forum ausgeblendet. ☺

• Bei mir sind samba_test und $USER identisch. Ist das bei Dir genau so? Wenn nicht, probier's mal so.

Ja, das hatte ich - glaube ich - schon mal mitgeteilt: Ich kann nur dann schreiben (losgelöst von den vorhandenen Rechten auf dem Server!), wenn der zum Zugriff auf den Share verwendete Samba-Account identisch mit dem Eigentümer des Shares ist. Also:

• der Share liegt im home von "samba_test" und hat daher als Eigentümer ebenfalls "samba_test"

• greife ich via gvfs mit der Kennung von "samba_test" auf den Share zu (unabhängig des lokal angemeldeten Benutzers) habe ich immer Schreibrechte, egal wie die Rechte auf den Server sind =⇒ genau das dürfte nicht sein!

• liegt der Share nicht im home, sondern bspw. in /opt, und ist der Eigentümer nicht "samba_test", kann auch kein Zugriff erfolgen (korrekte Beachtung der Rechte auf dem Server), auch wenn die Darstellung in gvfs das vermuten lässt

Das Verhalten passt aber nicht zu der Ausgangslage des TE. Sein Share liegt ja in /srv und nicht in /home. Allerdings: Der TE hat auf den Share ein 0777 raufgenagelt, ohne jedoch das Sticky Bit zu setzen. Und genau bei dieser Kombination kann jeder schreiben, auch wenn es Dateien innerhalb des Shares gibt, die root gehören und scheinbar nur von Dritten gelesen werden dürften. Sofern das Sticky-Bit gesetzt wird, wird die Datei auf dem Server nicht überschrieben. Es erfolgt zwar - zumindest bei mir - kein Hinweis, dass der Schreibvorgang nicht stattgefunden hat, die Datei auf dem Server ist jedoch in der ursprünglichen Form.

Haben wir jetzt vielleicht stundenlang aneinander vorbeigeredet? Ich sehe auf einmal den Unterschied gar nicht mehr:

greife ich via gvfs mit der Kennung von "samba_test" auf den Share zu (unabhängig des lokal angemeldeten Benutzers) habe ich immer Schreibrechte, egal wie die Rechte auf den Server sind =⇒ genau das dürfte nicht sein!

Richtig. Und genau das ist doch der Inhalt der Fehlermeldung. Das reicht doch, oder?

Auch nach deiner Anleitung kann ich es nicht nachstellen.

Das entspricht doch genau meiner "Anleitung". Dort handelt es sich nur um den Spezialfall, dass der angemeldete Benutzer eben auch "samba_test" ist. Doch, wie Du ja sagst, ist das Verhalten "unabhängig des lokal angemeldeten Benutzers". – Es stimmt allerdings, dass dies nicht mit der ursprünglichen Einstellung des Threadstarters identisch ist.

Doch auch wenn die Konstellation nicht der des Threadstarters entspricht, sind wir nicht off topic, denn wir sind ja beim Thema des Threads geblieben. Zurück zur Ausgangslage des Threadstarters:

Der TE hat auf den Share ein 0777 raufgenagelt, ohne jedoch das Sticky Bit zu setzen. Und genau bei dieser Kombination kann jeder schreiben, auch wenn es Dateien innerhalb des Shares gibt, die root gehören und scheinbar nur von Dritten gelesen werden dürften.

Ich sehe das ein bisschen anders. In Wikopedia steht:

Hat ein Verzeichnis beispielsweise für alle Benutzer alle Dateirechte gesetzt (777 bzw. rwxrwxrwx), dann kann jeder Benutzer in diesem Verzeichnis Dateien (und Unterverzeichnisse) anlegen, aber auch jede Datei darin löschen. Durch Setzen des Sticky-Bits wird der Zugriff auf die Dateien in diesem Verzeichnis eingeschränkt, so dass nur noch der Eigentümer einer Datei (oder der Eigentümer des Verzeichnisses) diese Datei löschen oder umbenennen darf. Die Rechte zum Lesen und Schreiben der Dateien bleiben davon unberührt.

Ich hatte dies immer so verstanden, dass zwar jedermann Dateien anlegen und löschen kann, nicht aber ohne Schreibrechte z.B. mittels echo "blablabla" > DATEI in eine vorhandene Datei hinein schreiben darf. Auf dem Server selbst geht das ja auch nicht, und über Samba/GVFS dürfte es dann auch nicht gehen. Doch genau dies hat ja der TE offenbar gemacht.

Moin.

Max-Ulrich_Farber schrieb:

Haben wir jetzt vielleicht stundenlang aneinander vorbeigeredet?

Na ich hoffe doch nicht ☺

greife ich via gvfs mit der Kennung von "samba_test" auf den Share zu (unabhängig des lokal angemeldeten Benutzers) habe ich immer Schreibrechte, egal wie die Rechte auf den Server sind =⇒ genau das dürfte nicht sein!

Richtig. Und genau das ist doch der Inhalt der Fehlermeldung. Das reicht doch, oder?

Ich hatte das immer so verstanden, das alle (also: others) Schreibrechte erhalten und nicht nur ein spezifischer Benutzer (der Eigentümer des Shares).

Auch nach deiner Anleitung kann ich es nicht nachstellen.

Das entspricht doch genau meiner "Anleitung". Dort handelt es sich nur um den Spezialfall, dass der angemeldete Benutzer eben auch "samba_test" ist. Doch, wie Du ja sagst, ist das Verhalten "unabhängig des lokal angemeldeten Benutzers". – Es stimmt allerdings, dass dies nicht mit der ursprünglichen Einstellung des Threadstarters identisch ist.

Genau. Das ist imho ein Spezialfall.

Doch genau dies hat ja der TE offenbar gemacht.

Letztlich fehlen imho da noch ein paar Angaben des TE, aber ja, ich lese es genauso raus. Ich konnte das Verhalten des TE nur nachvollziehen, wenn auf dem Share 0777 gesetzt wurde. Dann ist auch egal, wer der Eigentümer des Shares ist (root, "samba_test", o.ä.) und jeder kann in Dateien schreiben, auf die eigentlich der Server den Schreibzugriff verboten hat.

Hallo!

Hans9876543210 schrieb:

greife ich via gvfs mit der Kennung von "samba_test" auf den Share zu (unabhängig des lokal angemeldeten Benutzers) habe ich immer Schreibrechte, egal wie die Rechte auf den Server sind =⇒ genau das dürfte nicht sein!

Richtig. Und genau das ist doch der Inhalt der Fehlermeldung. Das reicht doch, oder?

Ich hatte das immer so verstanden, das alle (also: others) Schreibrechte erhalten und nicht nur ein spezifischer Benutzer (der Eigentümer des Shares).

Der Bugreport liest sich auch so. Da heißt es "any user having write permissions in that share". Wenn das nicht zutrifft, bitte den Bugreport editieren.

Viele Grüße

Vej

Immer diese verschiedenen Sprachen! Hätten die Dummköpfe doch damals den blöden Turmbau zu Babel bleiben lassen! Jetzt ist es leider zu spät. 😢

any user having write permissions in that share

heißt doch "alle Benutzer, die in dieser Freigabe Schreibrechte haben" (Partizip Präsens…). Und, soviel ich sehe, können alle diese Benutzer auch in die betreffende Datei schreiben. Es heißt nicht, dass allgemein alle Benutzer in die Datei schreiben können. Wenn others in der Freigabe keine Schreibrechte haben (ist bei mir so), dann sind demnach auch others nicht betroffen. Beim TE ("Status 0777 draufgenagelt") sind hingegen auch others betroffen.

Nach meinem rudimentären Sprachverständnis können wir die Fehlermeldung wohl so stehen lassen, wie sie ist.

Hallo Max-Ulrich_Farber.

Max-Ulrich_Farber schrieb:

Immer diese verschiedenen Sprachen! Hätten die Dummköpfe doch damals den blöden Turmbau zu Babel bleiben lassen! Jetzt ist es leider zu spät. 😢

any user having write permissions in that share

heißt doch "alle Benutzer, die in dieser Freigabe Schreibrechte haben" (Partizip Präsens…). Und, soviel ich sehe, können alle diese Benutzer auch in die betreffende Datei schreiben.

Ah, okay, dann hatte ich euch hier falsch verstanden. Ich dachte es ginge nur mit dem Nutzer, der auch Eigentümer des Shares ist.

Irgendwelche Neuigkeiten bezüglich einer Nachbauanleitung? Sollen wir die vielleicht hier Schrittweise aufbauen? Dann müsstest du eine grobe Anleitung posten, die wir dann ausprobieren und mit dir solange verfeinern, bis es auch für Nicht-Sambakenner funktioniert.

Viele Grüße

Vej

Bei deinem Beispiel hatte die Datei root:root. Ich denke, das sowohl der Benutzer root als auch die Gruppe root generell nicht beim Samba-Client vergeben ist, von daher können die Benutzer, die auf den Share zugreifen, nur in die Gruppe others gemappt werden. Oder?

Aber wir können das imho erstmal so stehen lassen und auf weiteres Feedback des TE warten, da wir mit unseren Ausführungen erstmal am Ende sind. Es sei denn es findet sich noch ein weiterer Tester ☺

@Hans9876543210:

Bei deinem Beispiel hatte die Datei root:root.

Stimmt.

Ich denke, das sowohl der Benutzer root als auch die Gruppe root generell nicht beim Samba-Client vergeben ist

Üblicherweise ist sie das schon. Oder was meinst Du mit "vergeben ist"?

von daher können die Benutzer, die auf den Share zugreifen, nur in die Gruppe others gemappt werden. Oder?

Die Benutzer, die über Samba zugreifen, sind üblicherweise weder root noch Mitglieder der Gruppe root. Also gelten für sie die Rechte, die bei der Datei für others festgelegt sind. Das meinst Du wohl mit "in die Gruppe others gemappt werden".

Aber Vorsicht: Das gilt so für die betreffende Datei, denn nur die gehört root:root. Der freigegebene Ordner kann aber jemand ganz Anderem gehören (bei mir $USER:$USER), und da gehören die Benutzer, die zugreifen, dann möglicherweise eben nicht zu others. Daher kommt ja das Dilemma: die Rechte werden beim GVFS (und nach Angaben von NetworkWarrior auch beim KIO-Slave) unberechtigterweise vom Ordner auf die enthaltene Datei übernommen, obwohl Eigentümer und Gruppe nicht dieselben sind. Und dies geschieht eben bei cifs-vfs und SMBNetFS nicht, was auch ok ist.

@Vej:

Ich dachte es ginge nur mit dem Nutzer, der auch Eigentümer des Shares ist

Der hat auf jeden Fall üblicherweise Schreibrechte. Mit dem geht es also. Aber je nach Dateimodus eventuell auch noch mit anderen.

Dann müsstest du eine grobe Anleitung posten, die wir dann ausprobieren und mit dir solange verfeinern, bis es auch für Nicht-Sambakenner funktioniert.

Ich bleibe dabei: Um eine funktionierende Verbindung über Samba herzustellen, muss man sich erst ein bisschen in das Thema einarbeiten. Nicht umsonst gibt es in unserem Wiki dazu mehr als ein halbes Dutzend Artikel. Das alles können wir nicht in der Nachbau-Anleitung unterbringen. Wir müssen davon ausgehen, dass diejenigen, die den Fehler nachbauen, die Grundlagen und Grundbegriffe von Samba schon kennen und in der Lage sind, eine einfache Standard-Samba-Verbindung herzustellen. Für diese Zielgruppe kann ich eine schrittweise Anleitung verfassen. Für Andere kann ich das nicht.

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

Üblicherweise ist sie das schon. Oder was meinst Du mit "vergeben ist"?

Siehe nächsten Post.

von daher können die Benutzer, die auf den Share zugreifen, nur in die Gruppe others gemappt werden. Oder?

Die Benutzer, die über Samba zugreifen, sind üblicherweise weder root noch Mitglieder der Gruppe root. Also gelten für sie die Rechte, die bei der Datei für others festgelegt sind. Das meinst Du wohl mit "in die Gruppe others gemappt werden".

Ja, genau das meinte ich.

Aber Vorsicht: Das gilt so für die betreffende Datei, denn nur die gehört root:root. Der freigegebene Ordner kann aber jemand ganz Anderem gehören (bei mir $USER:$USER), und da gehören die Benutzer, die zugreifen, dann möglicherweise eben nicht zu others. Daher kommt ja das Dilemma: die Rechte werden beim GVFS (und nach Angaben von NetworkWarrior auch beim KIO-Slave) unberechtigterweise vom Ordner auf die enthaltene Datei übernommen, obwohl Eigentümer und Gruppe nicht dieselben sind. Und dies geschieht eben bei cifs-vfs und SMBNetFS nicht, was auch ok ist.

Genau aus diesem Grund war ja auch meine Idee, einen dedizierten User inkl Gruppe für den Share anzulegen, der nicht auf Seite der Clients vorhanden ist. Dann sollte das Problem doch nicht auftreten. So ähnlich wird das doch auch bei Apache gemacht, wenn ich mich nicht täusche.

Eventuell ist auch ein Force User möglich, um die Clients auf einen speziellen User zu mappen. Das kann ich aber wahrscheinlich erst am Wochenende testen.

Ja, es gibt für den Fehler verschiedene, recht einfache Workarounds. Das ist gar kein Problem. Man legt z.B. die Datei irgendwo außerhalb der Share an und verlinkt sie nötigenfalls dorthin per Symlink. Samba folgt standardmäßig solchen wide links nicht, und alles ist geritzt. Es gilt hier sozusagen "Gefahr erkannt – Gefahr gebannt". – Doch der Fehler muss trotzdem weg, denn man muss sich einfach darauf verlassen können, dass kein gewöhnlicher Benutzer in Dateien schreiben kann, die root:root gehören mit Modus 0644. Das gehört einfach zur Zuverlässigkeit von Linux.

Moin.

Ich werde das bei Gelegenheit mit folgender Konstellation testen:

• Share gehört samba_test und der Gruppe 1234

• Datei innerhalb des Shares gehört root:root

• Client (nicht samba_test, sondern ein Benutzer der Gruppe 1234) versucht Schreibzugriff zu auf die root Datei zu kriegen

Sprich: entweder betrifft es nur "others" oder es kriegen tatsächlich alle Schreibzugriff AIF die root (was ja zu vermuten ist).

Edit: Das gleiche dann noch für eine Datei, die zwar nicht root:root hat, aber auch nicht samba_test:1234.

Ja, genau dieser Test steht noch aus. Und ich vermute das Gleiche wie Du. Man sollte dabei auch noch ein bisschen mit dem Dateimodus spielen. Denn der Benutzer der Gruppe 1234 sollte nach meiner Auffassung Schreibrechte in der Share (dem Ordner), nicht aber in der Datei haben. Das ist, soweit ich sehe, Bedingung für den an sich unerlaubten Schreibzugriff. Sprich: Wer in der Share schreiben kann, der kann es auch auf der Datei, ungeachtet deren abweichender Rechte.

Natürlich kann man noch versuchen, ob vielleicht auch noch Andere, die in der Share an sich keinen Schreibzugriff haben, auf die fremde Datei schreiben können. Doch dies scheint mir generell unmöglich.

Das gleiche dann noch für eine Datei, die zwar nicht root:root hat, aber auch nicht samba_test:1234.

Genau.

Im Übrigen machen wir hier schon weit mehr als eigentlich nötig. Um die Entwickler auf einen Fehler aufmerksam zu machen, genügt ein Beispiel, bei dem der Fehler auftritt. Unter welchen Bedingungen der Fehler sonst noch auftreten kann, müssen dann die Entwickler erkunden. Den Fehler zu analysieren und zu lokalisieren, bin ich als Ubuntuuser weder verpflichtet noch in der Lage. Dieser Schuh ist mir zu groß, den ziehe ich mir nicht an.

Hallo!

Max-Ulrich_Farber schrieb:

Im Übrigen machen wir hier schon weit mehr als eigentlich nötig. Um die Entwickler auf einen Fehler aufmerksam zu machen, genügt ein Beispiel, bei dem der Fehler auftritt. Unter welchen Bedingungen der Fehler sonst noch auftreten kann, müssen dann die Entwickler erkunden. Den Fehler zu analysieren und zu lokalisieren, bin ich als Ubuntuuser weder verpflichtet noch in der Lage. Dieser Schuh ist mir zu groß, den ziehe ich mir nicht an.

Das sehe ich auch so.

Eine (möglichst von Sambalaien) nachvollziehbare Reproduktionsanleitung und ggf. ein apport-collect 1664730 von einem Clientsystem auf dem der Bug auftritt sind auch alles was dem Bug fehlt um an die Entwickler weitergereicht zu werden.

Viele Grüße

Vej