Doug McNutt wrote:
> I think the point is that, for particular users, the ftpd daemon can
> be chrooted so that the user attempting to log in gets sent directly
> to a subdirectory of his home directory or to a read-only area that's
> well protected for anonymous access.
>
> By playing with permissions he can be limited to that starting point
> and can go nowhere else.

Um ... the first and only slash should be the root. For example, you
don't write http://www.google.com// -- the first slash after the
hostname is the root.

> The initial double slash gets back to the root providing the user is
> allowed to go there. It also shows up in scp and sftp used in an ssh
> environment.

Hang on ... you are saying that for a plain URL like this:

  ftp://user:pass@server/

you're not guaranteed to be at the root when you connect?

Now, I tried it: you are correct. It's possible to set up the FTP client
such that the URL's root is not the root of the log-in, so you can go to
paths like ftp://user:pass@server/../../foo

However, putting that extra slash in the URL isn't a great security
measure, as users can just bypass it. Anyone whose account is set up
such that you can traverse below the root, has a rather poor FTP admin
who should be taken out and shot :-P

Generally, the FTP server should treat the user's home folder as its own
root directory and not let them wander all over the server.

> If not getting out of a chroot you're probably right that double
> slashes are redundant and ignored.
>
> but then why is it ftp:// ??

Well, these two are mostly equivalent:

  <a href="http://www.google.com/">Google</a>
  <a href="//www.google.com/">Google</a>

I don't know how it applies to FTP (since FTP has no hyperlinks) but, //
seems to signify a URL that is starting with a domain, or something like
that. The latter doesn't define the protocol, so it assumes the same
protocol that is currently in force.
Received on 2007-02-02