|
Titel: Löschen - aber immer doch!?! Beitrag von: VolGas am 19. November 2005, 23:00:49 Hallo, alle mit einander!
Wir verwenden für unsere Kunden auf unserem kleinen Webserver schon länger erfolgreich ProFTPD (aktuell 1.2.10) mit mod_sql_mysql auf einem Debian-System. Es funktioniert soweit auch alles problemlos, nur eines nicht: egal welche Zugriffsrechte ein Verzeichnis oder eine Datei hat: es kann immer(!) gelöscht werden! Hier ein Extrembeispiel: Code: drwxr-x--- 2 1002 555 4096 Oct 15 2004 .access ---------- 1 0 0 256 Nov 19 21:12 test drwxrwx--- 7 1002 555 4096 Oct 24 10:19 web drwxr-x--- 2 1002 555 4096 Nov 26 2004 web_1 Die Datei "test" hat keine Zugriffsrechte, gehört dem root-User und kann weder heruntergeladen, noch sonst irgend etwas damit gemacht werden. Man erhält bei allem ein: "Permission denied" - wie es sich gehört. Aber Löschen - kein Problem! Hier unsere wichtigsten Settings: Code: [...] <Global> User nobody Group nogroup AuthOrder mod_sql.c ### Userident und -setting via mySQL SQLConnectInfo servicedb@localhost proftpd pass PERSESSION SQLUserInfo ftp userid passwd uid NULL homedir NULL SQLAuthTypes Plaintext SQLAuthenticate users* SQLMinUserUID 1000 SQLMinUserGID 555 SQLDefaultGID 555 DefaultRoot ~ Umask 017 007 ListOptions "-An +R" strict maxfiles 250 UseGlobbing off ShowSymlinks on AllowOverwrite on AllowRetrieveRestart on AllowStoreRestart on </Global> DefaultAddress www1 ServerName www1.irgendwo.de ServerAdmin hostmaster@irgendwo.de <VirtualHost www2> ... <\VirtualHost> Den Einsatz von "HideNoAccess on" würde zwar das Problem beseitigen, allerdings müssen wir darauf verzichten, da wir mit unterschiedlichen Benutzer- und Gruppenrechten arbeiten müssen. Das klappt mittels "umask" auch ganz hervorragend. Ich finde einfach den Fehler nicht und wäre um Hilfe sehr dankbar! mfg. VolGas Titel: Nachtrag... Beitrag von: VolGas am 21. November 2005, 15:03:59 Wir benutzen zwar Debain Stable, nutzen aber nicht dessen Server-Software, sondern haben diese selbst compiliert. Damit haben wir aktuellere Software und selbst mehr Kontrolle.
So wurde unser proFTPD compiliert: Code: ./configure \ --with-modules="mod_ifsession:mod_readme:mod_sql:mod_sql_mysql:mod_tls" \ --disable-auth-file --disable-auth-pam \ --disable-sendfile --enable-buffer-size=8092 \ --with-includes=/usr/local/mysql/include/mysql \ --with-libraries=/usr/local/mysql/lib/mysql \ \ --prefix=/usr/local/proftpd-1.2.10 \ --sysconfdir=/etc --localstatedir=/var/run --mandir=/usr/local/man \ \ CFLAGS="-O3 -fexpensive-optimizations" \ CXX=gcc CXXFLAGS="-O3 -felide-constructors -fexpensive-optimizations -fno-exceptions -fno-rtti" Damit haben wir bislang nur gute Erfahrungen gemacht. mfg. VolGas Titel: Re: Nachtrag... Beitrag von: stonki am 21. November 2005, 17:40:22 klingt wie:
http://www.proftpd.de/forum/viewtopic.php?t=307&highlight=rechte+root Titel: Löschen - aber immer doch!?! Beitrag von: VolGas am 22. November 2005, 01:29:44 Hallo Stonki,
vielen Dank für Deine Antwort. Das von Dir erwähnte Posting hatte ich bei meiner Suche gar nicht gefunden oder übersehen, sorry. Aber was da geschrieben steht, ist mir durchaus bekannt und bewußt. Ich habe leider noch vergessen zu erwähnen, daß bei jedem Homeverzeichnis auch das sog. "sticky bit" gesetzt ist. Das verhindert gerade eben im normalen Unix-Alltag, daß Dateien gelöscht werden können, die einem "nichts angehen" - auch wenn einem das Verzeichnis gehört. Ich vermute schon eine ganze Weile, daß ProFTPD mit dem sticky bit nix anzufangen weiß. Trozdem wundert es mich, denn gleich nach dem Einloggen des Users gibt der gestartete ProFTPD-Prozess seine Root-Rechte auf und läuft unter der User- und Gruppen-ID des angemeldeten Users. Da der Prozess dann keine Root-Rechte mehr hat (haben dürfte!), dürfte es auch nicht mehr möglich sein, fremde Dateien/Verzeichnisse zu löschen. In der Shell ist das zumindest nicht möglich. Was läuft da schief? Nochmals vielen Dank für die rasche Antwort! Vielleicht weißt Du (oder jemand anderes) was da los ist und vielleicht sogar, wie man das in normale Bahnen lenken kann - vielen Dank! mfg. VolGas Titel: Löschen - aber immer doch!?! Beitrag von: stonki am 22. November 2005, 09:07:34 also zu 100%. Das liegt nicht an ProFTPD, sondern an den Linux rechten. Was passiert denn wenn Du Dich als User auf der console einloggst ? Kannst Du dann das File löschen ?
Titel: Löschen - aber immer doch!?! Beitrag von: VolGas am 23. November 2005, 06:25:34 Hallo Stonki,
1.) vielen Dank für Deine Antwort und Deine Geduld 2.) Du hast Recht! Zu meiner Schande muß ich gestehen, daß ich die Funktionsweise des "Sticky Bits" nicht ganz "ausgelotet" hatte und im Vorfeld meines Postings es auch nicht noch einmal im o.g. Kontext ausprobiert hatte. Ich habe mich nun noch einmal "duchgelesen": Zitat Das Sticky Bit bei einem für alle zum Schreiben geöffneten Directory verhindert, daß sich Benutzer gegenseitig die in einem offenen Verzeichnis abgelegten Dateien weglöschen. Typische Anwendungen dieser Ausnahmeregelung sind die Verzeichnisse /tmp und /var/tmp. Ein solches Verzeichnis muß für alle zum Schreiben geöffnet sein. Ist das Sticky Bit auf einem solchermaßen schreiboffenen Verzeichnis gesetzt, so darf man in diesem Verzeichnis nur löschen oder umbenennen, wenn eine der folgenden Bedingungen erfüllt ist: * Die effective uid des löschenden oder umbenennenden Prozesses ist die des Eigentümers der Datei * Die effective uid des löschenden oder umbenennenden Prozesses ist die des Eigentümers des Verzeichnisses * Die Schreibberechtigung der zu löschenden oder umbenennenden Datei ist so freizügig gesetzt, daß man die Datei selbst beschreiben darf * man ist "Superuser" root Ich ging fälschlicherweise davon aus, daß das Sticky Bit prinzipiell verhindert, daß fremde Dateien gelöscht werden können, wenn man keine Schreibrechte an diesen hat. ProFTPD macht allso alles richtig... Ich muß mir eben etwas anderes einfallen lassen, vielleicht in dieser Art: Code: <Directory ~> HideFiles "^__system" </Directory> Damit könnte ich dann wichtige Files (oder gar ein ganzes Verzeichnis) vor dem User recht gut verstecken - es sei denn, er weiß, wo er zu suchen hat oder er liest per Script das Verzeichnis aus. Es ist mir peinlich und tut mir leid, Dich mit meiner Frage "belästigt" zu haben, aber vielleicht kommt irgendwann wieder so ein "Schlaumeier" wie ich - dann kannst Du ihn gerne auf diesen Artikel verweisen... Vielen herzlichen Dank auch dafür, daß es dieses offene Forum gibt und auch so hervorragend von Dir unterhalten wird! mfg. VolGas |