www.ProFTPD.de
13. März 2007, 20:27:39 *
Willkommen Gast. Bitte einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

Einloggen mit Benutzername, Passwort und Sitzungslänge
News: SMF - Neu installiert!
 
   Übersicht   Hilfe Suche Login Registrieren  
Seiten: [1]   Nach unten
  Drucken  
Autor Thema: Rechte für das ExtendedLog?  (Gelesen 177 mal)
0 Mitglieder und 1 Gast betrachten dieses Thema.
Wörsty
Moderator
ProFTPD
*****
Offline Offline

Beiträge: 1602


50772603
Profil anzeigen WWW E-Mail
« am: 21. Oktober 2003, 10:43:49 »

Jetzt habe ich auch mal eine Frage.
Wie kann ich festlegen, wer der Owner des ExtendedLog ist?
Bei mir ist das immer root. :shock:
Code:
LogFormat defaultftp "%h %l %u %t       %r %s %b"
ExtendedLog /www/vhosts/administration/linux/logfiles/proftpd_anonftp.log ALL defaultftp

Code:
-rw-r--r--    1 root     root          668 Okt 21 10:37 proftpd_anonftp.log

Code:
www       5767     1  0 10:45 ?        00:00:00 proftpd: (accepting connections)
www       5785  5767  0 10:45 ?        00:00:00 proftpd: anonymous - 10.138.134.

Ich will aber den Owner www haben.  :evil:  
Wie geht dem?  :??
Gespeichert

RedHat 8.0 (2.4er Kernel)
proftpd 1.2.10
-mod_sql_mysql
-mow_wrap
-mod_exec
-mod_ifsession[/size]
stonki
Administrator
ProFTPD
*****
Offline Offline

Beiträge: 1853


15318939
Profil anzeigen WWW E-Mail
« Antwort #1 am: 22. Oktober 2003, 16:37:03 »

Zitat von: "Wörsty"
Jetzt habe ich auch mal eine Frage.
Wie kann ich festlegen, wer der Owner des ExtendedLog ist?
Bei mir ist das immer root. :shock:
Code:
LogFormat defaultftp "%h %l %u %t       %r %s %b"
ExtendedLog /www/vhosts/administration/linux/logfiles/proftpd_anonftp.log ALL defaultftp

Code:
-rw-r--r--    1 root     root          668 Okt 21 10:37 proftpd_anonftp.log

Code:
www       5767     1  0 10:45 ?        00:00:00 proftpd: (accepting connections)
www       5785  5767  0 10:45 ?        00:00:00 proftpd: anonymous - 10.138.134.

Ich will aber den Owner www haben.  :evil:  
Wie geht dem?  :??


laut TJ geht das nicht anders...

cu
stonki
Gespeichert

www.stonki.de:    the more I see, the more I know.......
www.proftpd.de:   Deutsche ProFTPD Dokumentation
www.krename.net:  Der Batch Renamer für KDE
www.kbarcode.net: Die Barcode Solution für KDE
Wörsty
Moderator
ProFTPD
*****
Offline Offline

Beiträge: 1602


50772603
Profil anzeigen WWW E-Mail
« Antwort #2 am: 22. Oktober 2003, 17:06:30 »

Na gut.
Gespeichert

RedHat 8.0 (2.4er Kernel)
proftpd 1.2.10
-mod_sql_mysql
-mow_wrap
-mod_exec
-mod_ifsession[/size]
Gast
Gast
« Antwort #3 am: 22. Oktober 2003, 21:06:44 »

Zitat von: "Wörsty"
Na gut.


Aber ganz sicher geht das ... wenn ich deine Absichten richtig verstanden habe. Du möchtest also daß das Logfile dem User "www" gehört? Dafür gibt es sicher keine Einstellungen in der Konfiguration des proftpd. Das kannst du nur selbst erledigen. Ich hätte es nun so getan:

In dem du dich auf deiner Console mit dem Benutzernamen des jetzigen Besitzers des Logfiles anmeldest. Am besten wäre gleich der "root".

Mit dem Befehl:

>root# chown

kann man an einem Objekt oder Verzeichnis gleichzeitig den Besitzer und die Gruppe bestimmen.

So kannst du z.B. angeben:

>root# chown www:www /weißt/du/das/wirklich/nicht?/proftpd.log

... und das File proftpd.log hat nun den Besitzer "www" und die Gruppe "www". Das bleibt dann auch solange so bis du es selbst wieder änderst. proftpd wird diese Rechte nicht einfach ändern, glaube ich zumindest daß er das nicht von sich aus tut. Das wäre ein BUG der namentlich genannt werden müsste. Ist ja ein Sicherheitsrisiko wenn der Server selbst Besitzrechte erteilt.

Was du aber nicht tun solltest wäre: dem Logfile einen Besitzer zuordnen der mit dem Log nichts zu tun hat. Normalerweise sollte der Besitzer schon der jenige sein der auch die Erlaubnis hat den proftpd zu bedienen. Also der User der bei dir in der proftpd.conf steht. proftpd will ja in dieses File hineinschreiben. Es ist sowieso immer besser wenn man seine Log-Files von anfang an selbst anlegt und das nicht dem Server anvertraut.

Mit den Angaben in deiner proftpd.conf:

ExtendedLog                 /var/log/ex.log
TransferLog                  /var/log/trans.log
ServerLog                    /var/log/server.log

... gibt man zwar den genauen Standort der Files dem proftpd bekannt, erstellen tut der Server die Files aber lange noch nicht selbst. Vielmehr erwartet der Server diese Files dort an diesem Ort wenn er startet. Sind sie nicht da, bricht er wahrscheinlich den Start an dieser Stelle ab und zeigt Fehlermeldungen an. Legst du nun die Files gleich selbst an, hat das Log von Anfang an die Besitzrechte des Erstellers und das bleibt auch so bis es tot ist. Wird das Log vom System "gezippt", wird gleich ein neues mit den Besitzerrechten des ehemaligen Besitzers erstellt, sprich: die Rechte werden einfach vererbt. Erstellst du also ein File als "root" wird es auch immer "root" gehören bis du es änderst. Erstellst du ein File als "www", passiert genau das selbe und "www" bleibt der Besitzer.

Falls ich mit meinen Erläuterungen völlig daneben liege, ignoriere sie einfach, dann habe ich deine Frage falsch verstanden.

MfG
Gespeichert
Wörsty
Moderator
ProFTPD
*****
Offline Offline

Beiträge: 1602


50772603
Profil anzeigen WWW E-Mail
« Antwort #4 am: 22. Oktober 2003, 22:54:43 »

Danke für den Monstertext  :lol:

Fangen wir mal an:

Zitat von: "Gast"
Du möchtest also daß das Logfile dem User "www" gehört?

Ja.
Zitat von: "Gast"
Dafür gibt es sicher keine Einstellungen in der Konfiguration des proftpd.

Genau.
Zitat von: "Gast"
>root# chown www:www /weißt/du/das/wirklich/nicht?/proftpd.log

Ist mir schon klar.
Zitat von: "Gast"
proftpd wird diese Rechte nicht einfach ändern,

Jein.
Zitat von: "Gast"
Es ist sowieso immer besser wenn man seine Log-Files von anfang an selbst anlegt und das nicht dem Server anvertraut.

Mag sein.
Zitat von: "Gast"
erstellen tut der Server die Files aber lange noch nicht selbst. Vielmehr erwartet der Server diese Files dort an diesem Ort wenn er startet. Sind sie nicht da, bricht er wahrscheinlich den Start an dieser Stelle ab und zeigt Fehlermeldungen an

Falsch. Er tut es. Als root.root  :idea:
Zitat von: "Gast"
Falls ich mit meinen Erläuterungen völlig daneben liege, ignoriere sie einfach, dann habe ich deine Frage falsch verstanden

Nö, ist schon okay.
Ich teste das nochmal genau aus was wann wie passiert.
 :thx)
Gespeichert

RedHat 8.0 (2.4er Kernel)
proftpd 1.2.10
-mod_sql_mysql
-mow_wrap
-mod_exec
-mod_ifsession[/size]
Gast
Gast
« Antwort #5 am: 23. Oktober 2003, 02:47:59 »

Zitat von: "Wörsty"
Falsch. Er tut es. Als root.root  :idea:


So, tut er das? Das liegt aber nicht an proftpd, sondern an dir. Weil du deinem Verzeichnis /var/log weltweite Gruppen- und Schreibrechte erteilt hast. B.z.w. du hast diesem die genannten Rechte nicht entzogen. Mache es doch gleich richtig und bringe das erst einmal in Ordnung. Man sollte nur solchen Programmen diese Rechte im System zugestehen die nicht direkt mit der Außenwelt aggieren. Der Mailserver sendmail z.B., den du ja sicher auch kennst und vielleicht sogar bei dir wirken läßt, startet beispielsweise erst gar nicht wenn ihm diese Rechte für seine vorgegebenen Dateien und Verzeichnisse nicht vorher explizit entzogen worden sind. Dient alles nur Sicherheitsgründen und ist von den Entwicklern des Programms gleich so eingerichtet worden. Und ich meine es wirklich nur gut wenn ich das alles hier zu aller Langweiligkeit der Betroffenen rauslaufen lasse. Also ein FTP-Server erhält von mir nicht die Erlaubnis Dateien selbst zu erstellen, auch wenn es in diesem Falle nur Log-File sind. Ich empfehle dazu ganz einfach:

chmod g-w /var/log

... und fertig, so bist du immer auf der sicheren Seite.

proftpd startet ja nur als root. Bereits beim Parsen der proftpd.conf erhält er die Benutzerrechte die man dort eingetragen hat. In unserem Falle "www". Und als dieser wird er nun kaum mehr die Möglichkeit haben die Benutzerrechte des Log-Files zu ändern, b.z.w. ein neues zu erstellen.

Ich weiß, ich bin bekannt dafür ... aus Mücke macht Elefant.

Ist nun mal meine Meinung.

Und wenn man einen FTP-Server wirklich ernsthaft betreiben will, kann ich beispielsweise nur davon abraten diesen im Zusammenhang mit mysql zu verwenden. Natürlich auch nur aus Sicherheitsgründen. Es ist einfach praktisch erwiesen, daß es leichter ist eine Mysql-Datenbank zu knacken als eine netinfod. In fast jedem System hat diese ja einen anderen Namen.

Das aber nur nebenbei, weil ich gelesen habe daß du das Modul bereits in Gebrauch hast. Es eröffnet automatisch eine große Anzahl von Angriffsmöglichkeiten auf deine Datenbank in der ja mehr oder weniger wichtige Daten (womöglich Kundendaten, User, Passwörter) gespeichert sind. Ich weiß zwar jetzt nicht welches System du fährst, aber User und Gruppen kann man genauso gut und praktisch im System selbst anlegen, ohne daß die sich auch selbst am System anmelden können. Entschuldige bitte wenn ich mich hier so darüber auslasse, ist ja gar nicht das Thema.

Aber:

Lohnen tut sich der Komfort mit mysql erst bei einer gewissen Anzahl von Nutzern b.z.w. Benutzern eines FTP-Servers. Hat man dann mehr als hunderte Nutzer und Daten gespeichert, wären diese Daten mir in einer mysql-Datenbank zu unsicher untergebracht. Was meinst du dazu?

Nein, was ein Log-File so alles anrichtet :wink:
Gespeichert
stonki
Administrator
ProFTPD
*****
Offline Offline

Beiträge: 1853


15318939
Profil anzeigen WWW E-Mail
« Antwort #6 am: 23. Oktober 2003, 08:43:10 »

Zitat von: "Gast"
Zitat von: "Wörsty"
Falsch. Er tut es. Als root.root  :idea:


So, tut er das? Das liegt aber nicht an proftpd, sondern an dir. Weil du deinem Verzeichnis /var/log weltweite Gruppen- und Schreibrechte


Nein, das liegt an ProFTPD (Aussage vom ProFTPD Chefentwickler)


Zitat

proftpd startet ja nur als root. Bereits beim Parsen der proftpd.conf erhält er die Benutzerrechte die man dort eingetragen hat. In unserem Falle "www". Und als dieser wird er nun kaum mehr die Möglichkeit haben die Benutzerrechte des Log-Files zu ändern, b.z.w. ein neues zu erstellen.


nicht ganz richtig. ProFTPD läuft zwar mit den erwähnten Rechten, muss natürlich beim einloggen eines usern sich kurz die Root Privilegien holen, um z.B. Chroot auszuführen oder den Port zu benutzen. Siehe auch "RevokeRoot"

Zitat


Und wenn man einen FTP-Server wirklich ernsthaft betreiben will, kann ich beispielsweise nur davon abraten diesen im Zusammenhang mit mysql zu verwenden. Natürlich auch nur aus Sicherheitsgründen. Es ist einfach praktisch erwiesen, daß es leichter ist eine Mysql-Datenbank zu knacken als eine netinfod. In fast jedem System hat diese ja einen anderen Namen.


sehe ich anders. Es kommt natürlich immer das das gesamte Konzept an, aber im Regelfall ist die DB überhaupt nicht von aussen zu erreichen. Zu dem lohnen: die einfache administration lohnt sich auch bei wenigen usern. Auf dem einen Server hosten wir z.B. nur 5 Domains...

cu
stonki
Gespeichert

www.stonki.de:    the more I see, the more I know.......
www.proftpd.de:   Deutsche ProFTPD Dokumentation
www.krename.net:  Der Batch Renamer für KDE
www.kbarcode.net: Die Barcode Solution für KDE
Wörsty
Moderator
ProFTPD
*****
Offline Offline

Beiträge: 1602


50772603
Profil anzeigen WWW E-Mail
« Antwort #7 am: 23. Oktober 2003, 11:09:11 »

1. Ich habe momentan 903 User und die pumpe ich ganz sicher nicht als Systemuser in mein Linux - übrigens RedHat 8 (2.4.20-20.8smp) - sondern die bleiben mal schön in der Datenbank - übrigens mysql (3.23.58-1.80).

2. Die Daten werden laufend von PHP (4.3.2) übers Web (apache 1.3.27) bearbeitet und das macht sich mit mysql einfacher als ständig die passwd oder sonstwas zu parsen.

3. Mein Logfile liegt in /www/vhosts/administration/linux/logfiles und nicht /var/irgendwo - hatte ich aber auch geschrieben.

4. Die Rechte sind: drwxr-xr-x    3 www      www          4096 Okt 21 12:57 logfiles  

5. Laß gut sein. :wink:
Gespeichert

RedHat 8.0 (2.4er Kernel)
proftpd 1.2.10
-mod_sql_mysql
-mow_wrap
-mod_exec
-mod_ifsession[/size]
Seiten: [1]   Nach oben
  Drucken  
 
Gehe zu:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Prüfe XHTML 1.0 Prüfe CSS
Seite erstellt in 0.066 Sekunden mit 16 Zugriffen.