vsftp - chown für anonyme uploads
Hallo Liste. Ich richte mir gerade mit vsftp einen ftp-Server ein, und würde gern erreichen, daß Dateien, die anonym hochgeladen wurden, einem anderen user als ftp gehören. Dafür finde ich in der vsftpd.conf zwei Optionen: chown_uploads=YES chown_username=andre # Der User andre existiert! Wenn ich nun aber diese Optionen aktiviere, dann kann ich gar keine Dateien mehr hochladen. Vielmehr verliert der ftp-Client die Verbindung zum Server. Die Datei, die hätte hochgeladen werden sollen, ist dann zwar vorhanden, aber hat 0 Bytes Größe. Ich habe auch probiert, nur chown_uploads=YES zu setzen. So, wie ich die man-Page verstehe, sollten die Dateien in diesem Fall anschließend root gehören. Allerdings beobachte ich hier dasselbe Verhalten, wie wenn ich auch chown_username angebe. Deaktiviere ich beide Optionen, dann klappt der Upload, und die Dateien gehören ftp:ftp. Woran liegt das? -- Andre Tann
Andre Tann wrote:
Hallo Liste.
Ich richte mir gerade mit vsftp einen ftp-Server ein, und würde gern erreichen, daß Dateien, die anonym hochgeladen wurden, einem anderen user als ftp gehören. Dafür finde ich in der vsftpd.conf zwei Optionen:
chown_uploads=YES chown_username=andre # Der User andre existiert!
Wenn ich nun aber diese Optionen aktiviere, dann kann ich gar keine Dateien mehr hochladen. Vielmehr verliert der ftp-Client die Verbindung zum Server. Die Datei, die hätte hochgeladen werden sollen, ist dann zwar vorhanden, aber hat 0 Bytes Größe.
Ich habe auch probiert, nur
chown_uploads=YES
zu setzen. So, wie ich die man-Page verstehe, sollten die Dateien in diesem Fall anschließend root gehören. Allerdings beobachte ich hier dasselbe Verhalten, wie wenn ich auch chown_username angebe.
Deaktiviere ich beide Optionen, dann klappt der Upload, und die Dateien gehören ftp:ftp.
Woran liegt das?
Soweit ich weiss wird das chroot auf das Homeverzeichnis des Users ausgeführt. Dort müssen die Rechte so gesetzt werden, dass der eingeloggte ftp-user Schreibrechte hat. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Andre Tann wrote:
Sandy Drobic, Montag, 21. August 2006 13:10:
Soweit ich weiss wird das chroot auf das Homeverzeichnis des Users ausgeführt. Dort müssen die Rechte so gesetzt werden, dass der eingeloggte ftp-user Schreibrechte hat.
Verwechselst Du hier nicht chroot mit chown?
Yepp, nicht genau hingeschaut... Auf die Schnelle sehe ich allerdings auch keinen Grund, warum die Datei zwar angelegt werden kann, aber kein Inhalt geschrieben wird. Wer ist denn der Besitzer der Datei? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic, Montag, 21. August 2006 13:35:
Yepp, nicht genau hingeschaut... Auf die Schnelle sehe ich allerdings auch keinen Grund, warum die Datei zwar angelegt werden kann, aber kein Inhalt geschrieben wird. Wer ist denn der Besitzer der Datei?
ftp.ftp ...das war ein guter Tip. Ich habe mich mal in user ftp verwandelt, und dort touch datei abgesetzt. Das ging. Nicht aber ging chown andre.users datei "Die Operation ist nicht erlaubt". Das verstehe ich zwar noch nicht, weil das übergeordnete Verzeichnis dem User andre gehört, und die Berechtigung 777 hat. Aber ich werde es noch rausfinden... -- Andre Tann
...das war ein guter Tip. Ich habe mich mal in user ftp verwandelt, und dort
touch datei
abgesetzt. Das ging. Nicht aber ging
chown andre.users datei
"Die Operation ist nicht erlaubt".
Das verstehe ich zwar noch nicht, weil das übergeordnete Verzeichnis dem User andre gehört, und die Berechtigung 777 hat. Aber ich werde es noch rausfinden...
Das ist normal. Nur root darf den Besitzer einer Datei ändern.
Dominik Klein, Montag, 21. August 2006 13:50:
Das verstehe ich zwar noch nicht, weil das übergeordnete Verzeichnis dem User andre gehört, und die Berechtigung 777 hat. Aber ich werde es noch rausfinden...
Das ist normal. Nur root darf den Besitzer einer Datei ändern.
Hm, das habe ich in zwischen auch gemerkt. Aber was fange ich denn dann mit der entsprechenden Option in vsftpd.conf an? Wenn der ftpd als User ftp läuft und infolgedessen keine Dateien chownen kann, dann kann diese Funktion doch prinzipiell nicht arbeiten. Oder verstehe ich das nicht richtig? -- Andre Tann
Dominik Klein wrote:
...das war ein guter Tip. Ich habe mich mal in user ftp verwandelt, und dort
touch datei abgesetzt. Das ging. Nicht aber ging chown andre.users datei
"Die Operation ist nicht erlaubt".
Das verstehe ich zwar noch nicht, weil das übergeordnete Verzeichnis dem User andre gehört, und die Berechtigung 777 hat. Aber ich werde es noch rausfinden...
Das ist normal. Nur root darf den Besitzer einer Datei ändern.
Und mit etwas Nachdenken kann ich mich auch den Grund vorstellen... vi gimmerootshell.sh ..... chmod 777 gimmerootshell.sh chown root:root gimmerootshell.sh ./gimmerootshell.sh Vielleicht ist das ja auch so eine root-darf-sich-auch-in-den-Fuß-schießen-Option. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic, Montag, 21. August 2006 14:09:
vi gimmerootshell.sh ..... chmod 777 gimmerootshell.sh chown root:root gimmerootshell.sh ./gimmerootshell.sh
Klingt einleuchtend ;) Was ich dann allerdings mit der fraglichen Option in der vsftpd.conf anfangen soll, ist mir unklar... -- Andre Tann
Was ich dann allerdings mit der fraglichen Option in der vsftpd.conf anfangen soll, ist mir unklar...
Angenommen der vsftp liefe als root, würde das ja funktionieren. Das kann allerdings nicht des Rätsels Lösung sein. Schweigt sich die Doku dazu denn aus? Ich für meinen Teil habe ich noch nie mit dem Programm gearbeitet.
Dominik Klein, Montag, 21. August 2006 14:51:
Angenommen der vsftp liefe als root, würde das ja funktionieren. Das kann allerdings nicht des Rätsels Lösung sein.
Sehe ich auch so...
Schweigt sich die Doku dazu denn aus? Ich für meinen Teil habe ich noch nie mit dem Programm gearbeitet.
Da steht in der vsftpd.conf: # If you want, you can arrange for uploaded anonymous files to be # owned by a different user. Note! Using "root" for uploaded files # is not recommended! # #chown_uploads=YES #chown_username=andre Und in der man-page: chown_uploads If enabled, all anonymously uploaded files will have the owner- ship changed to the user specified in the setting chown_user- name. This is useful from an administrative, and perhaps secu- rity, standpoint. Default: NO chown_username This is the name of the user who is given ownership of anony- mously uploaded files. This option is only relevant if another option, chown_uploads, is set. Default: root Wenn ich die Diskussion bis hierher richtig verstanden habe, dann geht das überhaupt nur, wenn vsftpd als root läuft. Wie kann ich denn feststellen, als welcher Benutzer vsftpd läuft? Gestartet wird er jedenfalls über den xinetd, und dort steht in der entsprechenden Datei: user = root Also müßte der Daemon doch das chown machen können, es sei denn, daß er Rechte abgegeben hat und nicht wieder bekommen kann. -- Andre Tann
Andre Tann wrote:
Sandy Drobic, Montag, 21. August 2006 14:09:
vi gimmerootshell.sh ..... chmod 777 gimmerootshell.sh chown root:root gimmerootshell.sh ./gimmerootshell.sh
Klingt einleuchtend ;)
Was ich dann allerdings mit der fraglichen Option in der vsftpd.conf anfangen soll, ist mir unklar...
Ich kann mir eigentlich nur einen Grund vorstellen, und das ist, die Dateien, nachdem sie hochgeladen sind, dem Zugriff des Benutzers zu entziehen. So ganz einleuchtend ist diese Möglichkeit aber auch nicht... Wofür braucht du denn die Option? Welches Problem soll gelöst werden? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic, Montag, 21. August 2006 14:52:
Ich kann mir eigentlich nur einen Grund vorstellen, und das ist, die Dateien, nachdem sie hochgeladen sind, dem Zugriff des Benutzers zu entziehen. So ganz einleuchtend ist diese Möglichkeit aber auch nicht...
Wofür braucht du denn die Option? Welches Problem soll gelöst werden?
Genau, ich möchte die Datei nach dem Upload dem Zugriff anderer Benutzer entziehen. Denn es handelt sich ja um anonyme Uploads, und da geht es den einen nichts an, was der andere hochgeladen hat. Dies funktioniert auch jetzt schon, denn ich kann vsftp so einstellen, daß nicht-world-readable Dateien von anonymous nicht eingesehen werden können, und ich kann eine Rechtemaske derart vergeben, daß Dateien, die anonymous hochlädt, die Rechte 600 bekommen. Sprich: anonymous kann die selbst hochgeladene Datei, die ftp:ftp gehört, nicht lesen. Nun ist es aber so, daß ich das Upload-Verzeichnis immer wieder händisch einsehen und leeren möchte. Ich will aber nicht jedesmal root werden, ein chown auf alle hochgeladenen Dateien machen, um sie anschließend als User andre weiterbearbeiten zu können. Vielmehr möchte ich, daß die Dateien gleich mir gehören. Und das scheint mir auch der Sinn der Optionen chown_uploads=YES chown_username=andre zu sein. Allein - es funktioniert eben nicht. -- Andre Tann
Vielmehr möchte ich, daß die Dateien gleich mir gehören.
quick and dirty *g* while true do chown -R andre:andre /srv/ftp/upload/* sleep 10 done Das in nen Skript und per inittab respawnen lassen. (mir kräuseln sich auch bald die Zehennägel, aber damit hast du zumindest dein Problem gelöst)
Dominik Klein, Montag, 21. August 2006 15:59:
while true do chown -R andre:andre /srv/ftp/upload/* sleep 10 done
Hmpf... das ist die Brachial-Methode. Nun, wenn nichts anderes hilft, dann mache ich es so. Aber vorher möchte ich doch gerne sehen, ob man nicht doch den Mechanismus von vsftpd nutzen kann.
Das in nen Skript und per inittab respawnen lassen. (mir kräuseln sich auch bald die Zehennägel, aber damit hast du zumindest dein Problem gelöst)
Was heißt denn "respawnen lassen"? -- Andre Tann
Dominik Klein wrote:
Vielmehr möchte ich, daß die Dateien gleich mir gehören.
quick and dirty *g*
while true do chown -R andre:andre /srv/ftp/upload/* sleep 10 done
Das in nen Skript und per inittab respawnen lassen. (mir kräuseln sich auch bald die Zehennägel, aber damit hast du zumindest dein Problem gelöst)
Uh, ich glaube, genau so ein Brachialscript setzt eine Firma ein, mit der wir zusammenarbeiten, da laden wir ständig FTP-Dateien hoch, und die Dateien werden zerhäckselt. Vielleicht sollte wenigstens noch eine Prüfung mit lsof stattfinden, ob die Datei noch im Zugriff ist. for datei in `ls /srv/ftp/upload/*`; do if [ `lsof $datei` == "" ]; then { do your stuff... } fi done Ansonsten besteht die Gefahr, dass Dateien dem Hochladenden unter dem Hintern weggezogen werden. Cron ist IMHO etwas stabiler als die Endlos-Schlaufe und würde auch einen Neustart überstehen. Da so ein Script nur mit root-Rechten läuft, ist auf jeden Fall Vorsicht geboten. Vielleicht lädt ein netter Mensch ja Dateien hoch, die "rm -rf /*" heissen oder so ähnlich. (^-^) Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo, Am Mon, 21 Aug 2006, Sandy Drobic schrieb:
Vielleicht sollte wenigstens noch eine Prüfung mit lsof stattfinden, ob die Datei noch im Zugriff ist.
Ja.
for datei in `ls /srv/ftp/upload/*`; do
Das macht so nur Ärger bei Sonderzeichen im Dateinamen. Und das '*' expandiert so oder so die shell. for datei in /srv/ftp/upload/* ; do
if [ `lsof $datei` == "" ]; then [..] Endlos-Schlaufe und würde auch einen Neustart überstehen. Da so ein Script nur mit root-Rechten läuft, ist auf jeden Fall Vorsicht geboten. Vielleicht lädt ein netter Mensch ja Dateien hoch, die "rm -rf /*" heissen
Where did summer go? -- Geoff Let's see... *rifles through diary* Ah, yes. August 12th, 2:31-2:34pm. The sun peeped out from a crack in
Du rennst direkt in die nächste Falle, du quotest die Variable nicht. Also: if test "x`lsof $datei`" = "x"; then # ^ auch quoten ^ ^string Vergleich bei test ist mit "=" Ausserdem: ==== man lsof ==== Lsof returns a one (1) if any error was detected, includ ing the failure to locate command names, file names, Internet addresses or files, login names, NFS files, PIDs, PGRPs, or UIDs it was asked to list. It returns a zero (0) if no errors were detected and if it was able to list some information about all the specified search arguments ==== Und somit landen wir bei: for datei in /srv/ftp/upload/* ; do if ! lsof "$datei" >/dev/null; then ... # ^ ^ fi done HTH, -dnh -- the clouds, between a light shower and a torrential downpour. -- Peter
David Haller wrote:
Hallo,
Am Mon, 21 Aug 2006, Sandy Drobic schrieb:
Vielleicht sollte wenigstens noch eine Prüfung mit lsof stattfinden, ob die Datei noch im Zugriff ist.
Ja.
for datei in `ls /srv/ftp/upload/*`; do
Das macht so nur Ärger bei Sonderzeichen im Dateinamen. Und das '*' expandiert so oder so die shell.
for datei in /srv/ftp/upload/* ; do
Habe gerade das nächste Problem gesehen: was ist mit Verzeichnissen? Also vermutlich noch ein "test -f $datei". Ansonsten müsste bei Verzeichnissen wohl "lsof $datei/*" genommen werden, sonst würde das Verzeichnis chowned werden, während der Transfer noch läuft.
if [ `lsof $datei` == "" ]; then [..] Endlos-Schlaufe und würde auch einen Neustart überstehen. Da so ein Script nur mit root-Rechten läuft, ist auf jeden Fall Vorsicht geboten. Vielleicht lädt ein netter Mensch ja Dateien hoch, die "rm -rf /*" heissen
Du rennst direkt in die nächste Falle, du quotest die Variable nicht. Also:
Grins! Ich zum Glück nicht. (^-^)
if test "x`lsof $datei`" = "x"; then # ^ auch quoten ^ ^string Vergleich bei test ist mit "="
Stimmt, die Quotezeichen habe ich vergessen. Der Vergleichsoperator "==" ist zumindest bei der Bash erlaubt.
Ausserdem:
==== man lsof ==== Lsof returns a one (1) if any error was detected, includ ing the failure to locate command names, file names, Internet addresses or files, login names, NFS files, PIDs, PGRPs, or UIDs it was asked to list.
It returns a zero (0) if no errors were detected and if it was able to list some information about all the specified search arguments ====
Und somit landen wir bei:
for datei in /srv/ftp/upload/* ; do if ! lsof "$datei" >/dev/null; then ... # ^ ^ fi done
Bei Verzeichnissen klappt das leider nicht mehr, das müsste noch ergänzt werden, aber nicht mehr diese Nacht. (^-^) Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo, Am Die, 22 Aug 2006, Sandy Drobic schrieb:
David Haller wrote:
Am Mon, 21 Aug 2006, Sandy Drobic schrieb:
Vielleicht sollte wenigstens noch eine Prüfung mit lsof stattfinden, ob die Datei noch im Zugriff ist. for datei in `ls /srv/ftp/upload/*`; do
Das macht so nur Ärger bei Sonderzeichen im Dateinamen. Und das '*' expandiert so oder so die shell.
for datei in /srv/ftp/upload/* ; do
Habe gerade das nächste Problem gesehen: was ist mit Verzeichnissen? Also vermutlich noch ein "test -f $datei". Ansonsten müsste bei Verzeichnissen wohl "lsof $datei/*" genommen werden, sonst würde das Verzeichnis chowned werden, während der Transfer noch läuft.
Jup. Wobei: ein FTPD der den Namen verdient sollte es ermöglichen "MDIR" für "incoming" abzuschalten. D.h. innerhalb des "incoming" gibt es nur Dateien. Da würde das simple for f in /srv/ftp/upload/*; do ausreichen. Falls dem nicht so wäre sollte man find verwenden (s.u.).
if [ `lsof $datei` == "" ]; then [..] [..] Du rennst direkt in die nächste Falle, du quotest die Variable nicht. Also:
Grins! Ich zum Glück nicht. (^-^)
Dann ischa gut ;)
if test "x`lsof $datei`" = "x"; then # ^ auch quoten ^ ^string Vergleich bei test ist mit "="
*ARGH* Ich war wohl auch schon müde: das innere quoten! Und das mir! Also: if test "x`lsof \"$datei\"`" = "x"; then ^ ^^ ^^ ^ Wenn man $() statt `` verwendet ist das Verhalten anders.
Stimmt, die Quotezeichen habe ich vergessen.
Gewöhne es dir bitte an immer zu quoten -- mindestens wenn du es an die ML schreibst. Was du bei dir riskierst ist ja dein Ding ;)
Der Vergleichsoperator "==" ist zumindest bei der Bash erlaubt.
$ /usr/bin/test "x" == "x" /usr/bin/test: ==: binary operator expected $ /usr/bin/test --version test (GNU sh-utils) 1.16 $ test "x" == "x" $ echo $? 0 $ echo $BASH_VERSION 2.03.0(1)-release Relevant ist, neben dem Binary vor allem erstmal http://www.opengroup.org/onlinepubs/007908799/xcu/test.html Und das dokumentiert klar ==== s1 = s2 True if the strings s1 and s2 are identical. s1 != s2 True if the strings s1 and s2 are not identical. ==== Den Vergleich mit "=" können alle mir bekannten (normalen) Shells wie bash, ash, ksh, pdksh, zsh und sogar die tcsh. Ergo: man nehme "=" und nicht "==" ;) BTW: ich mag '[' nicht, schon allein wg. der seltsamen Anforderung eines ']' als letzten Argument, der nötigen Leerzeichen, und weil es wie ein shell-Konstrukt aussieht, aber ein Befehl ist. Und wie oft sieht man so seltsame Konstrukte wie: kommando if [ "$?" != "0" ] ; then (wobei hier noch der Stringvergleich verschärfend hinzukommt *ARGS*) wenn ein einfaches: if kommando; then reicht. Den konkreten Returncode braucht man ja eher selten, und dann muß man den eh in einer Variablen ablegen, z.B.: kommando retval=$? if ! test $retval -eq 0; then case $retval in ... esac fi oder, etwas kompakter: if ! { kommando; retval=$?; test $retval -eq 0; }; then case $retval in ... esac fi (statt "test $retval -eq 0" kann man es umkehren zu "test $retval -ne 0" und dafür das "!" beim "if" weglassen, so finde ich den Test aber "semantisch" passender ;)). [..]
Und somit landen wir bei:
for datei in /srv/ftp/upload/* ; do if ! lsof "$datei" >/dev/null; then ... # ^ ^ fi done
Bei Verzeichnissen klappt das leider nicht mehr, das müsste noch ergänzt werden, aber nicht mehr diese Nacht. (^-^)
==== find /srv/ftp/upload/ -mindepth 1 -print0 | xargs -r -0 ftp_incoming_chown.sh ==== ==== ftp_incoming_chown.sh ==== for x; do lsof "$x" >/dev/null || chown andre.blubb "$x" done ==== Das sollte eigentlich sicher sein, aber keine Gewähr, ich bin schon etwas arg müde und habe obiges auch nicht getestet. Durch das "-mindepth 1" wird das Upload-Verzeichnis ausgelassen, aber raufgeladenen Verzeichnisse auch bearbeitet. Ansonsten könnte man ein '-type f' einbauen und/oder im chown-script noch ein test -f "$x" || continue ergänzen. Achso: "find .. -print0" und "xargs -0" sind leider nicht portabel. -dnh -- | $ rpm -q --whatrequires kernel | no package requires kernel Ach ja, dascha interessant! Kein RPM braucht das? Ja wie? Dann kann ich das RPM ja also beruhigt loeschen? Braucht ja keiner... [ich, hier]
participants (4)
-
Andre Tann
-
David Haller
-
Dominik Klein
-
Sandy Drobic