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
Kai,
Am 08.04.10 12:31, schrieb Kai Schaetzl:
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.
Yes, I thought so too. I did not receive any reply from the author, and there is no vsftpd list - at least I did not find one on the project site.
-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.
I am sorry, I must have overlooked the answer. I would have been happy to find it.
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.
If I could force the users of the ftp server to use ASCII filenames I gladly would.
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.
Since the source is no way to go I had hoped to find other people with similar experience to find a workaround or a solution. I am sorry for disturbing.
Dirk
Dirk H. Schulz wrote on Thu, 08 Apr 2010 14:55:26 +0200:
Since the source is no way to go
Try harder. I'm sure you'll get a response sooner or later. You could also bug it at both the CentOS and RHEL bugzilla. You will need to give clear reproduction instructions.
Kai
-
Dirk H. Schulz -
Kai Schaetzl