CentOS - Apr 2010 - vsftpd saving uploads twice

I have configured my vsftpd instances to use virtual users and map them 
to a system user. So all uploads should be written with owner and group 
of this system user (let's call it ftpsystemuser).

But in the the last weeks/months it appears that uploads are written 
twice, on instance as it should (owner and group of the system user used 
to map the virtual user that did the upload), and the other instance as 
root. Lik this:
> -rw-r--r-- 1 root          root          19968 16. M?r 11:24 Termine 
> Leistungspr%FCfungen.doc
> -rw-r--r-- 1 ftpsystemuser ftpsystemuser 19968 16. M?r 11:24 Termine 
> Leistungspr?fungen.doc
As you can see both instance use different syntax for the file name in 
case of German umlauts. In vsftpds log only the correct file is mentioned.

Can anybody tell me what is happening here? Is this something I can get 
rid off using certain configuration? Is it a security problem?

Any hint or help is appreciated.

Dirk

Dirk H. Schulz wrote on Thu, 08 Apr 2010 11:29:53 +0200:

Can you please stop this? You are repeating your messages to the list with 
slightly changed subjects and content because you apprently don't get the 
answers you want. This is unfriendly, please stop this! And spare lame 
excuses.

Did you consider to talk to the vsftpd author/list? I think it's obvious 
that your problem is easier solvable with/by them.
> > -rw-r--r-- 1 root          root          19968 16. M?r 11:24 Termine 
> > Leistungspr%FCfungen.doc
> > -rw-r--r-- 1 ftpsystemuser ftpsystemuser 19968 16. M?r 11:24 Termine 
> > Leistungspr?fungen.doc
In the other thread from two days ago you got an answer that you elected to 
ignore. But this answer may have a clue to your problem. If it is true that 
the file is first written as root and then rewritten (instead of chowned) to 
another user then the above can be the result of an encoding conversion 
problem. The filename contain umlauts and the first filename is uploaded 
with a %encoded name. I may be wrong but I think this encoding should be 
only transitory and re-transcribed to the characters fitting there in with 
the system's character-set when the file is written to storage. The %
encoding for that character is correct, maybe the filesystem cannot or need 
not handle %encoding, but nevertheless tries to convert to an existing 
character instead of letting the "%FC" live as is. And this fails.
What's obvious, is that the file then gets written with an unknown character
in it. So, some part of the character conversion either doesn't work 
correctly or cannot work correctly, for instance because a character-set is 
set incorrectly on one of the involved systems and clients.
If you used ASCII filenames the problem wouldn't exist, of course.
This could be a bug in vsftpd or in the OS or a combination or in your 
client or something else. So, again, you should go to the source, which is 
vsftpd.


Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com