Opened 6 years ago

Last modified 6 years ago

#8986 new Bug report

directory path wrongly extracted from url (problems on chrooted accounts)

Reported by: blm Owned by:
Priority: normal Component: FileZilla Client
Keywords: chroot, path, directory Cc:
Component version: Operating system type: Windows
Operating system version:

Description

when we currently paste such ftp path
(s)ftp://user:password@host/directory
into filezilla it's extracted in the way:

user
password
host
/directory

the last part is not corrected
it should be just "directory"
without leading slash

why it make different?

on most ftp systems, root directory == user directory (and it make no difference)

when - for security reasons - account is chrooted, then slash from beginning point outside user directory and the path can't be found

example:

(s)ftp://user:password@host/directory

on our system (with chroot)
/bin
/data (it's user "home" directory)
/data/directory
/dev
/etc
....

so runing
cd /directory
will fail, but when you login (your current directory is set to /data) and try
cd directory
(relative path) everything will work fine.

so the whole bug is about removing 1st slash from directory path.
(only 1st, because path like (s)ftp://user:password@host//data/directory should work - in this case your using absolute path)

such way of parsing path is used for example in FF (and other programs)

if you have any questions please let me know.

I can also prepare test (valid for 24h) account on our system
(but I can't share it by ticketing system, so please mail me if such account would be helpful)

Regards,
Bartosz

Change History (6)

comment:1 Changed 6 years ago by Alexander Schuch

comment:2 Changed 6 years ago by blm

Just for reference: http://tools.ietf.org/html/rfc1738#section-3.1 ;)

url-path

The rest of the locator consists of data specific to the
scheme, and is known as the "url-path". It supplies the
details of how the specified resource can be accessed. Note
that the "/" between the host (or port) and the url-path is
NOT part of the url-path.

rfc3986 updates rfc1738 (don't replace it)

so far I tested:
Firefox 24
Chrome 30.0.1599.69
TotalCommander 7.56a
all above works fine [TotalComander had the same issue in the past]

InternetExplorer 8.0
FileZilla 3.7.3
failed

comment:3 Changed 6 years ago by blm

http://tools.ietf.org/html/rfc1738#section-3.1
[...]

For example, the URL <URL:ftp://myname@host.dom/%2Fetc/motd> is
interpreted by FTP-ing to "host.dom", logging in as "myname"
(prompting for a password if it is asked for), and then executing
"CWD /etc" and then "RETR motd". This has a different meaning from
<URL:ftp://myname@host.dom/etc/motd> which would "CWD etc" and then
"RETR motd"; the initial "CWD" might be executed relative to the
default directory for "myname". On the other hand,
<URL:ftp://myname@host.dom//etc/motd>, would "CWD " with a null
argument, then "CWD etc", and then "RETR motd".

[...]

comment:5 Changed 6 years ago by Tim Kosse

This is really complex.

As for ftp://myname@host.dom/%2Fetc/motd, I wonder how that is to be interpreted. As per RFC 3659, segments may not contain slashes, yet it is the first segment of a relative paths as per the URI specs.

How to specify absolute paths for use in FTP URLs?

comment:6 Changed 6 years ago by blm

[this is algorithm used on our server-side downloading scripts and probably similar to this from programs I listed before]

in ftp://myname@host.dom/%2Fetc/motd
you have to cut from url everything after 1st slash [after domain] so: "%2Fetc/motd" in this case, then do urldecode which gives you "/etc/motd" then do
CWD /etc/motd [and you have absolute path]

in ftp://myname@host.dom//etc/motd [commonly used]
you have to cut from url everything after 1st slash [after domain] so: "/etc/motd" in this case, then do urldecode which gives you "/etc/motd" then do
CWD /etc/motd [and you have absolute path]

in ftp://myname@host.dom/test
you have to cut from url everything after 1st slash, [after domain] so: "test" in this case, then do urldecode which gives you "test" then do
CWD test

of course
CWD /etc/motd
will fail because it's a path to the file

[THIS IS EXTRA FEATURE:]
but you can try to do something like this:

CWD /etc/motd
if it fails => try to access a directory higher [if there is any]
CWD /etc

do whatever is necessary, list folder content, download file etc.

Hope it's sounds reasonable [definitely it's working];)

Note: See TracTickets for help on using tickets.