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

[blm]

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

[Alexander Schuch]

Just for reference: ​http://tools.ietf.org/html/rfc3986#section-3.3.

[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

[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".

[...]

[blm]

sorry, it was ​http://tools.ietf.org/html/rfc1738#section-3.2.2

[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?

[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];)