> If a getcwd() function fails in ftpd.c::pwd(), the ftp server may
> produce a bad reply message.

>  > ftp> cd /hidden/zzz		<=== /hidden is set with d--x--x--x
>  > 250 CWD command successful.
>  > ftp> pwd
>  > 550 or allowed) ftp access	<=== Garbage!
>  > ftp> pwd                          In this case, "or allowed) ftp access"
>  > .                                 is a text of /etc/ftpusers!
>  > ftp> ls -l
>  > 550 or allowed) ftp access   <=== Garbage!
>  > .
>  > ftp> ls -l
>  > 200 PORT command successful.
>  > 425 Can't build data connection: Connection refused. <=== Ah.
>  > ftp> ls -l
>  > 200 PORT command successful.
>  > 150 Opening ASCII mode data connection for '/bin/ls'.

This looks as though the server is getting out of sync with the client.
Try a "reset" after each 550.  Not that that fixes the problem, of
course.

>  	if (getcwd(path, sizeof(path) - 1) == NULL)
> -		reply(550, "%s.", path);
> +		reply(550, "Can't get the current directory.");

This looks as though someone changed getwd() to getcwd() without
noticing that the error semantics are not the same.  The reply() call
should probably be something like

	reply(550, "getcwd: %s.", strerror(errno));

>  	if (getcwd(cwd, sizeof(cwd) - 1) == NULL) {
> -		syslog(LOG_WARNING, "can't malloc");
> +		syslog(LOG_WARNING, "can't getcwd");

Similarly here, though here one could perhaps make an argument for
using %m (I wouldn't; until an extension mechanism exists for printf,
using non-printf formats in things that are mostly printf-compatible
strikes me as a bad idea).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B