Description of problem: With the last update of vsftpd service, uploaded files are created with 000 rights even if local_umask=002 for example (i refuse anonymous login). Version-Release number of selected component (if applicable): vsftpd 1.2.1-3E.12 How reproducible: All the time i upload files. Steps to Reproduce: 1. update vsftpd to version 1.2.1-3E.12 2. login to your ftp server 3. upload files and look at the perms Actual results: with local_umask=002 files created are with perms 000 Expected results: with local_umask=002 files' rights have to be 664 Additional info:
We are experiencing this as well and have downgraded back to 1.2.1-3E.6 for the time being.
Same thing. Same package version (vsftpd-1.2.1-3E.12.i386.rpm), same behavior.
I have also experienced this issue. The unexpected file permissions are not always 000, sometimes they are 065. Changing local_umask seems to have no effect at all on what the file permissions end up being.
we're having the same problem. upload file permissions seems pretty random. we had to downgrade vsftpd.(In reply to comment #0)
This problem caused a critical data delivery problem for us. The severity needs to be raised to urgent. We'll downgrade, but that is not an acceptable solution for us.
Ditto the above symptom - caused numerous issues with incoming ftp transfers over the last few days - have backed out to .6 - please raise the priority of the issue for resolution
Created attachment 158105 [details] Patch to correct upload permissions Please try this patch. Thanks
Created attachment 158110 [details] Replacement for rename patch to correct filehandle leak
Created attachment 158111 [details] Replacement for upload_perms patch to correct permissions problem
Created attachment 158117 [details] Better patch vsftpd-1.2.1-rename.patch and vsftpd-1.2.1-upload_perms.patch stay unchanged.
Created attachment 158123 [details] Updated replacement for upload_perms patch This fixes both the permission problem and the handle leak.
Usage of the test packages in IT#125010 solved the problem for quite a few of my customers.
Usage of the test packages in IT#125010 solved the problem for all three of my customers who had the problem. Any chances to get a supported update released ?
*** Bug 247786 has been marked as a duplicate of this bug. ***
New RPM today? :)
*** Bug 248061 has been marked as a duplicate of this bug. ***
this is urgent...
isn't this dragging on a bit? it's a pretty nasty bug, introduced with U9.
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being marked as a blocker for this release. Please resolve ASAP.
I should note that rebuilding from 1.2.1-3E.12 src rpm with the patches kindly provided, or just trying to build the src rpm period, fails: [kf@joyce rpm]$ cat /etc/issue Red Hat Enterprise Linux ES release 3 (Taroon Update 9) [kf@joyce rpm]$ rpmbuild -ba SPECS/vsftpd.spec ...sysdeputil.c: In function `capset': sysdeputil.c:152: can't find a register in class `BREG' while reloading `asm' make: *** [sysdeputil.o] Error 1 make: *** Waiting for unfinished jobs.... error: Bad exit status from /var/tmp/rpm-tmp.52068 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.52068 (%build)...
Nevermind... was broken dependency. Needed libcap-devel (In reply to comment #38) > I should note that rebuilding from 1.2.1-3E.12 src rpm with the patches kindly > provided, or just trying to build the src rpm period, fails: > > [kf@joyce rpm]$ cat /etc/issue > Red Hat Enterprise Linux ES release 3 (Taroon Update 9) > > [kf@joyce rpm]$ rpmbuild -ba SPECS/vsftpd.spec > > ...sysdeputil.c: In function `capset': > sysdeputil.c:152: can't find a register in class `BREG' while reloading `asm' > make: *** [sysdeputil.o] Error 1 > make: *** Waiting for unfinished jobs.... > error: Bad exit status from /var/tmp/rpm-tmp.52068 (%build) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.52068 (%build)...
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 the 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/RHBA-2007-0757.html