Frage zu FTP-Server / Berechtigung

[Gero013]

Hallo,

habe bftpd und vsftpd ausprobiert, aber irgendwie kann ich die Server nicht so konfigurieren, wie ich das gerne hätte.

Mir schwebt ein public Verzeichnis mit sticky-Bit vor, in dem "jeder" schreiben darf, aber keiner die Datei eines anderen löschen können soll (seine eigene schon).

Mit der benutzerspezifischen Konfiguration bei vsftpd kann ich Benutzer Schreibrechte erteilen oder entfernen, aber die Dateirechte werden nicht beachtet.

Geht das, was ich vorhabe überhaupt und wenn ja, wie muss ich vorgehen?

Gruß Gero

 

[olistudent]

Hammer bald alle "Anfängerfragen" durchgekaut? Samba vermisse ich bis jetzt noch. ;-)

Welches Dateisystem hast du denn? Auf Linux Dateisystemen sollten die Rechte schon beachtet werden.

MfG Oliver

 

[Gero013]

Hammer bald alle "Anfängerfragen" durchgekaut?

iptables ist noch offen

Im Prinzip will ich nur 2 Erweiterungen durch Freetz (DMZ und FTP mit unterschiedlichen Berechtigungen), aber der Weg dahin ist mühsam.

Samba vermisse ich bis jetzt noch. ;-)

Wirst Du bei mir nicht erleben

Welches Dateisystem hast du denn? Auf Linux Dateisystemen sollten die Rechte schon beachtet werden.

ext2

Habe mit unterschiedlichen Benutzern und beiden ftp-Servern getestet - die Datei-Rechte wurden in keinem Fall beachtet.

Gruß Gero

 

[olistudent]

/ # ps |grep vsftpd
 7523 root      1224 S    vsftpd
 7539 ftpuser   1224 S    vsftpd
 7541 oliver    1248 S    vsftpd
 7545 root      1156 S    grep vsftpd

read(0, "DELE test\r\n", 14)   = 14
getcwd("/var/media/ftp/uStor01", 4096)  = 23
unlink("test")                 = 0

Hm, ich versteh es auch nicht. Wenn ich eine Datei mit dem Benutzer root anlege, dann müsste sich doch der vsftpd, wenn er als anderer Benutzer läuft an diese Berechtigung halten!?

MfG Oliver

 

[RalfFriedl]

Welche Rechte hat das Verzeichnis?

 

[Gero013]

Hm, ich versteh es auch nicht. Wenn ich eine Datei mit dem Benutzer root anlege, dann müsste sich doch der vsftpd, wenn er als anderer Benutzer läuft an diese Berechtigung halten!?

Freut mich, dass wir einer Meinung sind.
Genau so hatte ich es auch probiert

Welche Rechte hat das Verzeichnis?

Das ist doch völlig irrelevant

Gruß Gero

 

[olistudent]

drwxrwxrwx   22 root     root          1024 Jun 17 17:52 .
drwxr-xr-x    5 root     root          1024 Jun 17 17:16 ..

Ohne x darf ich es gar nicht browsen.

MfG Oliver

 

[RalfFriedl]

Dann ändere mal die Rechte vom Verzeichnis auf 1777.

 

[olistudent]

Scheint zu funktionieren. Ich kann nur noch die eigenen Dateien löschen.

The sticky-bit on directories forces the behavior that (within that directory with the sticky-bit set) only the owner of the file can remove the file. The same applies to directories within that directory that has the sticky-bit set. To continue the above example, joe could also create a directory in /tmp that jane couldn't remove.

Ich kannt die vierte Bit-Gruppe noch gar nicht...

MfG Oliver

 

[Silent-Tears]

Ich kannt die vierte Bit-Gruppe noch gar nicht...

Mach mal ein "ls -l / |grep tmp" und schau mal, was du da für Rechte hast. Sidn exakt diese.

 

[RalfFriedl]

Scheint zu funktionieren.

Sollte es auch besser. Der FTP-Server kann sich nicht über die Zugriffsrechte des Systems hinwegsetzen.

Mir schwebt ein public Verzeichnis mit sticky-Bit vor

Welche Rechte hat das Verzeichnis?

Das ist doch völlig irrelevant

Manchmal verstehe ich Dich wirklich nicht. Oben macht es den Eindruck, als wüßtest Du genau, was es mit dem Sticky-Bit auf sich hat, und nachher schreibst Du, daß die Rechte des Verzeichnisses irrelevant sind? Was hast Du dann oben für Rechte gesetzt, die nicht beachtet werden?

@Silent-Tears
Statt "ls -l / |grep tmp" auch "ls -ld /tmp".

@all
Kurzer Ausflug in Zugriffsrechte für Verzeichisse:
r: Wird benötigt, um das Verzeichnis zu lesen, also eine Liste der vorhandenen Namen zu bekommen.
w: Wird benötigt, um das Verzeichnis zu ändern. Änderungen sind Anlegen, umbenennen und löschen von Einträgen. Wichtig: um eine Datei zu löschen, braucht man nur Schreibrechte auf das Verzeichnis, nicht auf die Datei selbst. Durch das Löschen ändert sich nichts am Inhalt der Datei.
x: Wird benötigt, um auf einen Eintrag zugreifen zu können. Wenn ein Eintrag namentlich bekannt ist, braucht man kein Leserecht auf das Verzeichnis, um auf den Eintrag zuzugreifen.

 

[Gero013]

Manchmal verstehe ich Dich wirklich nicht. Oben macht es den Eindruck, als wüßtest Du genau, was es mit dem Sticky-Bit auf sich hat, und nachher schreibst Du, daß die Rechte des Verzeichnisses irrelevant sind? Was hast Du dann oben für Rechte gesetzt, die nicht beachtet werden?

Nun, meiner Ansicht nach kommt das Sticky-Bit erst dann zum tragen, wenn andere Berechtigungen vorliegen:

Beispiel:
BenutzerA und BenutzerB sind beide in der Gruppe Anwender.

-rw-r--r-- 1 BenutzerA Anwender 5 18. Jun 05:03 test

Wenn jetzt BenutzerB die Datei löschen will, bekommt er eine Warnung, dass die Datei schreibgeschützt ist, verbunden mit der Frage, ob er die Datei löschen will.
Wird dies bestätigt und das Verzeichnis hat Schreibrechte für die Gruppe, dann wird die Datei gelöscht.
Liegt kein Schreibrecht für die Gruppe vor, wird das Löschen verweigert.

-rw-rw-r-- 1 BenutzerA Anwender 5 18. Jun 05:03 test

Bei diesen Dateirechten kommt keine Warnung, sondern die Datei ist gleich weg.

Also bin ich davon ausgegangen, dass ein Stickybit erst bei vorliegender Berechtigung "befragt" wird. Die Datei eines anderen zu löschen, ohne vorliegende Berechtigung empfinde ich als Vergewaltigung der Dateirechte!
Ebenso wie die Einstellung, dass das Löschen nix an der Datei ändern würde. Absurd!
Da ich mit Gruppenrechten arbeite, habe ich die Frage nach dem Stickybit gestellt.

Gruß Gero

 

[RalfFriedl]

Das Stickybit wird erst bei vorliegender Berechtigung "befragt", in dem Sinn, daß es eine Einschränkung der sonst vorhandenen Rechte ist. Wenn man keine Schreibrechte auf das Verzeichnis hat, kann man nichts löschen. Wenn man sie hat, kommt noch die Prüfung auf Stickybit und Eigentümer dazu.

Die Warnung von rm kommt grundsätzlich, wenn man keine Schreibrechte hat, auch wenn man selbst der Eigentümer ist. Die Warnung ist aber eben nur eine Warnung und hat nichts damit zu tun, ob das Löschen zulässig ist. Wenn man keine Rechte zum Löschen hätte, könnte man auch nicht löschen, auch nicht nachdem man zehnmal bestätigt hat. Die Warnung läßt sich außerdem mit der Option -f abschalten.
So ganz habe ich dem oben trotzdem nicht entnehmen können, welchen Unterschied das Stickybit machen sollte. Oder ging es dabei nur um die Warnung von rm?

Und genau genommen führt rm eine unlink-Operation aus, genau wie der FTP-Server in #4 von Oliver. Und eine unlink-Operation ist keine Änderung am Inhalt der Datei.

Wenn Du aber oben tatsächlich das Stickybit gesetzt hättest, dann hättest Du Dateien von anderen Benutzern nicht löschen können. Was also hattest Du oben tatsächlich gemacht?

 

[hermann72pb]

Ich habe so eine Idee diesbezüglich: Es wäre nicht schlecht die Benutzerverwaltung "für Dummies" via WebIF zu gestalten. Ich kenne das z.B. von meiner NAS QNAP. Da gibt es so eine Art Wisard mit 3-5 Abfragen / Masken beim Anlegen eines Benutzers. Man wird gefragt, welcher Gruppe der Benutzer gehören sollte, wo seine Dateien liegen sollen und ob sie per SAMBA/FTP freigegeben werden sollten.
Da du sowas in deinen autorun/autoend-Skripten sowieso implementiert hast, Gero013, wäre die Idee nah es in Form eines Pakets oder einer Erweiterung für FREETZ zu gestalten. Wenn das Anlegen von Benutzer zentral per WebIF geschieht, kann da nichts schief gehen und die Rechte werden immer so gesetzt, wie sie sein sollen.

MfG

 

[gismotro]

Sorry,
aber wird das nicht Overruled mit den Rechten die ihr dem User über die Experteneinstellung des Vsftp vergebt ?
So ist es zumindestens im Newbie-Howto beschrieben......

 

[Gero013]

aber wird das nicht Overruled...

Das kann man so sehen, ...

Mir gefällt, dass, seit das Berechtigungsproblem geklärt ist, es keinen Grund mehr für mich gibt, vsftpd einzusetzen. Ich bin zurück zum schlankeren bftpd.
Der kann chrooting, kann die gleichen Benutzer, wie vsftpd verwenden und die Parameter, die man nicht übers webIF setzen kann, habe ich im Paket gepanscht, sodass ich jetzt sehr zufrieden bin

Gruß Gero