Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 240550

Summary: vsftpd has a create/lock race condition which corrupts uploads
Product: Red Hat Enterprise Linux 4 Reporter: Martin Poole <mpoole>
Component: vsftpdAssignee: Martin Nagy <mnagy>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.5CC: bpeters, mbarabas, mnagy, tao
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHSA-2008-0680 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-24 19:34:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to handle write race condition on simultaneous upload
none
new patch to handle write race condition none

Description Martin Poole 2007-05-18 12:55:17 UTC 
Description of problem:

There is a race condition in the open/lock code which is triggered when two
clients upload to the same file. The lock is only obtained after the file is
opened and in the case of the second client to causes the client to hang until
the first client completes. The problem is that both opens are performed with
O_TRUNC | O_APPEND which in the second client's case truncates the first
client's progress to that point. Once the first client completes and releases
the lock the second client then appends to whatever the first client uploaded
after the second client performed the open.  This results in a file which is
neither one thing nor the other.

Version-Release number of selected component (if applicable):

vsftpd-2.0.1-5.EL4.5

How reproducible:

Always.

Steps to Reproduce:
1. Simultaneously upload different files from 2 clients to same file on server
2.
3.
  
Actual results:

Uploaded file is combination of tail of first client + second file.

Expected results:

One or the other file.

Additional info:

best reproduced by using large files or limiting upload rate.
Comment 1 Martin Poole 2007-05-18 12:55:19 UTC 
Created attachment 154992 [details]
patch to handle write race condition on simultaneous upload
Comment 2 RHEL Program Management 2007-11-29 04:20:06 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 3 Martin Nagy 2007-11-29 08:33:51 UTC 
Created attachment 272551 [details]
new patch to handle write race condition

This patch also respects read lock on the file that is being overwritten.
Comment 4 Michal Nowak 2007-11-30 09:21:18 UTC 
Use RHTS test case
       /CoreOS/vsftpd/regressions/testbug_para_upload
for testing.
Comment 5 Martin Nagy 2007-11-30 09:31:05 UTC 
Forgot that vsftpd-2.0.1 doesn't support locking.
Comment 6 Martin Nagy 2007-12-04 12:32:04 UTC 
Fixed in fedora/rawhide (vsftpd-2.0.5-21.fc9).
Comment 8 Martin Nagy 2008-02-08 10:50:34 UTC 
Fix checked in CVS and the new packages were built successfully. This issue
should be resolved in vsftpd-2.0.1-6.el4
Comment 12 errata-xmlrpc 2008-07-24 19:34:52 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2008-0680.html