kpf fails to serve file names containing ~
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
KDE Network |
Unknown
|
Medium
|
|||
kdenetwork (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: kpf
kpf (KDE's public file server) doesn't serve files whose names contain the character "~" and returns HTTP error 403 (forbidden). For example, setup a simple test directory and create two files:
mkdir ~/testdir
touch ~/testdir/file1.txt
touch ~/testdir/
Export testdir with kpf. Now try to get the files:
wget http://
--- OK
wget http://
--18:54:19-- http://
=> `file1~beta.txt'
Resolving localhost... 127.0.0.1
Connecting to localhost|
HTTP request sent, awaiting response... 403 Forbidden
18:54:19 ERROR 403: Forbidden.
This doesn't seem like a big problem at first, but I had to serve as an improvised package mirror from my Kubuntu laptop. kpf is the easiest way to set it up. Unfortunately some of the packages contained "~".
Changed in kdenetwork: | |
status: | Unknown → In Progress |
Changed in kdenetwork: | |
status: | Confirmed → Triaged |
Changed in kdenetwork: | |
status: | In Progress → Invalid |
Changed in kdenetwork: | |
status: | Invalid → Unknown |
Changed in kdenetwork: | |
importance: | Unknown → Medium |
I think I have isolated the problem in the source. It is in kdenetwork- 3.5.6/kpf/ src/Server. cpp lines 252-265: QFileInfo
// If there's .. or ~ in the path, we disallow. Either there's a mistake
// or someone's trying to h@x0r us. I wouldn't have worried about ~
// normally, because I don't do anything with it, so the resource would
// simply not be found, but I'm worried that the QDir/QFile/
// stuff might try to expand it, so I'm not taking any chances.
if (d->request. path(). contains( "..") || d->request. path(). contains( '~')) readyToWrite( this));
{
kpfDebug << d->id << ": readRequest: bogus path" << endl;
d->state = Responding;
respond(403);
emit(
return false;
}
I am not familiar with KDE development, so I am not sure whether the author is correct that QDir/QFile/ QFileInfo expand "~". It seems strange and in any case forbidding all files containing "~" is not the correct solution for sure. I will e-mail the upstream author (which I probably should have done on the first place, before reporting it here).