Subject: Re: ftpd and LIST command
To: None <tech-net@netbsd.org>
From: Quentin Garnier <cube@cubidou.net>
List: tech-net
Date: 02/07/2005 10:09:18
--WfZ7S8PLGjBY9Voh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 07, 2005 at 08:49:05AM +0100, Richard Braun wrote:
> On Mon, Feb 07, 2005 at 02:28:45PM +1100, Luke Mewburn wrote:
> > On Sun, Feb 06, 2005 at 08:01:26PM +0100, Richard Braun wrote:
> > | It seems the netbsd ftpd doesn't handle LIST commands correctly. LI=
ST alone
> > | works right, but LIST <path> fails (returns no list at all). PR #12=
667
> > | is about this problem and is still open. Is it a bug or a missing f=
eature ?
> >=20
> > Works for me, for "simple" filenames or directories:
> >=20
> > ftp> debug
> > Debugging on (debug=3D1).
> > ftp> dir bin
> > ---> EPSV
> > 229 Entering Extended Passive Mode (|||19251|)
> > ---> LIST bin
> > 150 Opening ASCII mode data connection for '/bin/ls'.
> > total 608
> > -r-xr-xr-x 1 0 0 289068 Nov 2 2000 ls.off
> > 226 Transfer complete.
> >=20
> > I haven't (recently) investigated the specific bug described in PR 1266=
7.
>=20
> Right. Actually, the problem rises when the command isn't strictly format=
ted
> as "CMD ARG". For example, LIST / works, LIST / doesn't... I don't think
> the RFCs would forbid such commands.
Then read the RFC :)
My idea is that the ftp client should be the one sanitizing the command in
that case.
Besides, consider the case where the file or directory name starts with
a space. The FTP protocol itself doesn't have any way to escape it.
--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
--WfZ7S8PLGjBY9Voh
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
iQEVAwUBQgcwPtgoQloHrPnoAQJZMwgApVe7Y7Xgho038lm9EbLeytoNYCNxeAgx
N7tVHU0B+KAwVUrq8mc/SBFVlYaLYcGU369h8JpdCn7CPPm3KkMM15CnWNdAfFCo
tNcbBgWSRp8ESYLSrH9a1CPT6+q7pbYQlKLeuOJDgaCPsUby8iJEznfy8U41LpYQ
DK61jple414wlY7zG9t7+JqcWVROsMrQbPbX5nM5GO+zXb6j8l8DyPAxFIcCJqqL
qu4R4ZO2Q2pmBHoaGn/wZEMaiYfkLEG+UxDEwRrpqmwAu0uuzQlDo5DtLc7ztKgy
UjL/ZI3qY/J1mGmy5R+uhWgF3061ndkcj0JeEKRAlsFRsGKa0niIWw==
=AA5T
-----END PGP SIGNATURE-----
--WfZ7S8PLGjBY9Voh--