Löschen - aber immer doch!?!

[VolGas]

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

[VolGas]

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

[stonki]

klingt wie:

http://www.proftpd.de/forum/viewtopic.php?t=307&highlight=rechte+root

[VolGas]

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

[stonki]

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 ?

[VolGas]

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":

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