Bugzilla – Bug 361559
Vsftpd file locking, does not work
Last modified: 2009-04-21 15:25:51 UTC
VsFTPd file locking does not work. See bug: https://bugzilla.redhat.com/show_bug.cgi?id=240553 I see this is not fixed in 10.3. $ cat vsftpd-2.0.5-file-locking.patch diff -Naur vsftpd-2.0.5-vanilla/sysutil.c vsftpd-2.0.5/sysutil.c --- vsftpd-2.0.5-vanilla/sysutil.c 2008-02-13 10:31:46.000000000 -0600 +++ vsftpd-2.0.5/sysutil.c 2008-02-13 10:30:24.000000000 -0600 @@ -1144,8 +1144,7 @@ int vsf_sysutil_create_overwrite_file(const char* p_filename) { - return open(p_filename, O_CREAT | O_TRUNC | O_WRONLY | - O_APPEND | O_NONBLOCK, + return open(p_filename, O_CREAT | O_TRUNC | O_WRONLY | O_NONBLOCK, tunable_file_open_mode); }
11.0 needs this patch also. In my organization we still use 9.3, so I'd really enjoy seeing an rpm for that version.
This is the same problem reported on #273454 for SLE ( but is a private report)
This patch is not really a solution. It is only working because you are trying with the same file. With your patch the result is always file1 overlayed by file2. Look at this example: $ md5sum some.iso e92c90a23fe9c1b4dd35bf114282b997 some.iso $ l some.iso -rw-r--r-- 1 root root 1512357888 2007-10-10 02:38 some.iso $ md5sum other.iso 3abddaaa6db96472dc9dfc4c8bf4a331 other.iso $ l other.iso -rw-r--r-- 1 root root 1500473344 2007-10-10 02:56 other.iso $ date; curl -s -T some.iso ftp://earl/anon/vsftpd-file-locking; date Fri Mar 14 15:11:47 CET 2008 $ date; curl -s -T other.iso ftp://earl/anon/vsftpd-file-locking; date Fri Mar 14 15:11:53 CET 2008 This should result in upload 2 beeing blocked by upload 1 (until finished) and then in vsftpd-file-locking beeing the same as other.iso. The result is actually $ md5sum vsftpd-file-locking 6992b07798a1abc291c7d2fec53a07eb vsftpd-file-locking $ l vsftpd-file-locking -rw-r--r-- 1 ftp ftp 1512357888 Mar 14 15:16 vsftpd-file-locking So again something mangled. The other patch in redhats bugzilla is also only fixing their testcase and not the problem (you can even truncate the file to zero by aborting upload2). This needs further investigation by chris i guess.
In order for the second upload to block, you need lock_upload_files=YES Without that option, uploads will not be locked and simultaneous uploads will corrupt files. I believe this was added in 2.0.3. After fixing as previously described (removing O_APPEND) and turning file locking on, vsftpd works as it should. See below: $ date; curl -s -T test1 --user noland:password ftp://`hostname`/vsftp-file-locking; date Fri Mar 14 10:19:52 CDT 2008 Fri Mar 14 10:20:17 CDT 2008 $ date; curl -s -T test2 --user noland:password ftp://`hostname`/vsftp-file-locking; date Fri Mar 14 10:19:54 CDT 2008 Fri Mar 14 10:20:44 CDT 2008 $ ls -l test* vsftp-file-locking -rw-r--r-- 1 noland noland 512000000 Mar 14 09:59 test1 -rw-r--r-- 1 noland noland 512000000 Mar 14 10:03 test2 -rw------- 1 noland noland 512000000 Mar 14 10:20 vsftp-file-locking noland@swat:~$ md5sum test* vsftp-file-locking 5d39c60a88631ced7dd766904e2a789d test1 2a929f81fe80636097ac6a4d936f511a test2 2a929f81fe80636097ac6a4d936f511a vsftp-file-locking
Yes that works because test2 fits into test1. Now try with test1 being bigger then test2 or the other way around.
Upstream is not really reacting to this. So we will go with the patch red-hat is using so we at least get consistent behavior. Anja can we make this an 11.0 update?
*** Bug 273454 has been marked as a duplicate of this bug. ***
Hello Novell, I reopen here because updates not get mirrored when Novell site is closed. This seems to be a write race condition in vsftpd due to insufficient locking. hans-georg: what do you want to tell me? which update isn't mirrored when what is closed? the bug? I have a patch for this. Can you see if the package on ftp.suse.com/pub/people/hvogel/273454/ fixes this for you? Thorsten do you want this in SP2? Sorry but another testcase showed that this solution has other implications. 1) With the version in SLES10 up to the the newest version of vsftpd you get file + file (so 2 times big_example.iso in one file) 2) With the proposed patch you get file1 with an overlay of file2 So this help when the file uploaded is the same (because you overlay the file with itself) but breaks if you upload another file. This really needs further thinking in the file locking of vsftpd. I contact the upstream author. ------- Comment From cijurajan@in.ibm.com 2008-06-05 11:05 EDT------- Novell, Any update on this issue? upstream is not reacting to this. There is one solution that fixes this problem but it has other issues. Mainly with aborting an "waiting for locked file" upload producing a truncated to 0 file. Which is very unexpected behavior. *** This bug has been marked as a duplicate of bug 361559 ***
Created attachment 222247 [details] proposed patch
------- Comment From rosalesa@us.ibm.com 2008-08-04 13:46 EDT------- Novell, Is this a fix we should expect to see in SLES11? -Thanks for your support.
this one is fixed in 11.0 SLES10-SP2 and SLES11
------- Comment From rosalesa@us.ibm.com 2008-09-04 18:49 EDT------- (In reply to comment #55) > ------- Comment From hvogel@novell.com 2008-09-02 04:24:42 MDT------- > this one is fixed in 11.0 SLES10-SP2 and SLES11 Novell, Thank you for the update. We are currently working on verifying the fix.
Just for the record, this bug has been fixed in upstream, vsftpd version 2.1.0