Subject: Problems with current Bero and VR code.

From: "Randall S. Winchester" <[email-masked]>
Date: Tue, 16 Mar 1999 12:16:47 -0500 (EST)

Hi, I have just recently tried both BeroFTPD-1.3.4 and wu-ftpd-2.4.2-vr16.
The bottom line is that I like them! Thanks for the good work.

There were some problems that both had, and that just Bero had.

Bero:

Your realpath.c does not work for "private" user directories that are
mounted over NFS-V3, in particular if the NFS server is a Solaris box.
If the directory is mode 700 (our default), realpath will fail.
The problem is you can not chdir() or getcwd() as root, since root does not
have privlages over NFS. The fix is to try the chdir() or getcwd() as the
user first, then failover to the setuid() attempt. After making these
changes to the Bero code I relaized the VR code had almost exactly the same
changes...

AFS support is missing two calls to "ktc_ForgetAllTokens();". Not releasing
the tokens in a timely fashon can cause problems on a busy ftp server. a
busy server. They are needed in dologout() just before the _exit(status);
and at the end of end_login(). (VR does not *come* with AFS support)

Bero and VR:

SYST is only allowed after check_login(). This breaks "RapidFiler (sp?)"
which tries to autodetect the type of system before login. This is a NetWare
thing, that I have recieved reports from. My fix was to take that
restriction back out of ftpcmd.y.

LOG_FAILED can log users passwords. The feature is enabled by default. This
has been well understood in the "telnetd", "sshd", "xdm" world, were
experiance has show that users will put their password where their login
name belongs. (often from typing to fast, or not paying attention). You
should never log the_user in failed logins. The other places where "name" is
logged, is after the "name" is verified to be a valid username (i.e after
sgetpwnam(name) is called). I consider this a potential security risk!
My fix was to log everything but "the_user"...an ident call here might be
inorder if you wanted to dig further.

MAPPING_CHDIR works well unless you try and "dir <path>" where path is a
symlink. This is the frequent case with automounted homes. It is common for
/homes/$USER to be a symlink to /somewhere/over/the/rainbow/$USER.
When you run "dir /homes/rsw" (in my case) you do not get the expected
result. I have had reported problems with with a number of PC ftp programs
that do just this, and fail in various ways, including not being able to
upload files. (The programs run the offending command as part of there
internal "protocal"). My fix was to change ls_long and ls_short in ftpd.c to
also include the "-L" flag to "ls". 

Overall I like the work that has been done, and I thank you both for your
efforts.

Randall

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 16 Mar 1999 16:09:31 -0500 (EST)

On Tue, 16 Mar 1999, Randall S. Winchester wrote:

> SYST is only allowed after check_login(). This breaks "RapidFiler
> (sp?)" which tries to autodetect the type of system before login. This
> is a NetWare thing, that I have recieved reports from. My fix was to
> take that restriction back out of ftpcmd.y.

bug report this to "RapidFiler (sp?)" and or Netware.  Their client is
non-compliant.

RFC959
  4.1.1.  ACCESS CONTROL COMMANDS
    USER NAME (USER)

    This command will normally be the first command transmitted by the
    user after the control connections are made (some servers may require
    this).

The WU-FTPD-VR server requries USER to be the first command by refusing to
allow any other commands until after a Login Sequence has been completed.
BeroFTPD allows HOST before USER in support of the ftp-wg proposed draft.
ISTM the proposed draft makes this requirement even more stringent.

SYST before USER is non-compliant and the client should be corrected.

> LOG_FAILED can log users passwords. The feature is enabled by default.

Noted.  I'll change it in a future VR version.  (Personally, I think any
admin who leaves his log files unsecured deserves what he gets.)

> MAPPING_CHDIR works well unless you try and "dir <path>" where path is
> a symlink. This is the frequent case with automounted homes. It is
> common for /homes/$USER to be a symlink to
> /somewhere/over/the/rainbow/$USER. When you run "dir /homes/rsw" (in
> my case) you do not get the expected result. I have had reported
> problems with with a number of PC ftp programs that do just this, and
> fail in various ways, including not being able to upload files. (The
> programs run the offending command as part of there internal
> "protocal"). My fix was to change ls_long and ls_short in ftpd.c to

Solaris?  Not SunOS?  I've been chasing a problem recently on SunOS which
may related to this kind of odd behavior.  What I'm finding is Sun's NFS
system is pretty buggy.  Are you using NFS?  If so, try changing the
#define HAVE_GETCWD in src/config/config.sol to an #undef and rebuilding
the daemon.  On SunOS this fixed all kinds of odd things even when NFS
wasn't being used.

Did the -L flag fix everything?  (I find it hard to believe it would.)  If
so, can you think about that this is telling us about MAPPING_CHDIR and
send me some details of what it did before which was wrong and now that
it's right?

General note to readers: Please remember 'dir <path>' means nothing to us.
Some clients use NLST, others use LIST .. if you don't indicate which is
being used there's not much can be done to help you.

In this case, you're talking about changing ls_long and ls_short, so you
must be talking about the LIST command.  Without that hint I'd have no
handle on where to look for your issues.

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: "Randall S. Winchester" <[email-masked]>
Date: Tue, 16 Mar 1999 17:32:58 -0500 (EST)

On Tue, 16 Mar 1999, Gregory A Lundberg wrote:

: On Tue, 16 Mar 1999, Randall S. Winchester wrote:
:
: > MAPPING_CHDIR works well unless you try and "dir <path>" where path is
: > a symlink. This is the frequent case with automounted homes. It is
: > common for /homes/$USER to be a symlink to
: > /somewhere/over/the/rainbow/$USER. When you run "dir /homes/rsw" (in
: > my case) you do not get the expected result. I have had reported
: > problems with with a number of PC ftp programs that do just this, and
: > fail in various ways, including not being able to upload files. (The
: > programs run the offending command as part of there internal
: > "protocal"). My fix was to change ls_long and ls_short in ftpd.c to
: > also include the "-L" flag to "ls".
: 
: Solaris?  Not SunOS?  I've been chasing a problem recently on SunOS which
: may related to this kind of odd behavior.  What I'm finding is Sun's NFS
: system is pretty buggy.  Are you using NFS?  If so, try changing the
: #define HAVE_GETCWD in src/config/config.sol to an #undef and rebuilding
: the daemon.  On SunOS this fixed all kinds of odd things even when NFS
: wasn't being used.
: 
: Did the -L flag fix everything?  (I find it hard to believe it would.)  If
: so, can you think about that this is telling us about MAPPING_CHDIR and
: send me some details of what it did before which was wrong and now that
: it's right?

Original code:

ftp> pwd
---> PWD
257 "/homes/lwinc" is current directory.
ftp> dir /homes/lwinc
---> PORT 129,2,8,129,223,9
200 PORT command successful.
---> LIST /homes/lwinc
150 Opening ASCII mode data connection for /bin/ls.
lrwxrwxrwx   1 root     wheel         39 Mar 16 16:57 /homes/lwinc ->
/afs/glue.umd.edu/home/elves/lwinc/home

With the added -L flag:

ftp> pwd
---> PWD
257 "/homes/lwinc" is current directory.
ftp> dir /homes/lwinc
---> PORT 129,2,8,129,223,13
200 PORT command successful.
---> LIST /homes/lwinc
150 Opening ASCII mode data connection for /bin/ls.
total 1050
drwxr-xr-x  10 lwinc    daemon      4096 Oct 27 15:11 .
drwxr-xr-x   7 root     daemon      2048 Sep 23 07:55 ..
-rw-------   1 lwinc    33536        218 Feb  5  1998 .Xauthority
[....snip....]
drwx------   2 lwinc    staff       2048 Nov  4  1994 mail
226 Transfer complete.
remote: /homes/lwinc
4002 bytes received in 2.4 seconds (1.7 Kbytes/s)

Now a "LIST" with no arguments works, but I did some packet sniffing to
determine the some GUI clients call "LIST <path>. In fact I saw this
happening as a precursor to a RETR. Getting the symlink back confused the
gui so it failed the transfer.

: Solaris?  Not SunOS?  I've been chasing a problem recently on SunOS which
: may related to this kind of odd behavior.  What I'm finding is Sun's NFS
: system is pretty buggy.  Are you using NFS?  If so, try changing the
: #define HAVE_GETCWD in src/config/config.sol to an #undef and rebuilding
: the daemon.  On SunOS this fixed all kinds of odd things even when NFS
: wasn't being used.

I am using Solaris, not SunOS (today). I am using an automounter that may
point to either NFS or AFS directories. (The NFS was only an issue with the
realpath.c code that you did correctly).

I get the same behaviour with or without "HAVE_GETCWD" defined.

: Did the -L flag fix everything?  (I find it hard to believe it would.)  If
: so, can you think about that this is telling us about MAPPING_CHDIR and
: send me some details of what it did before which was wrong and now that
: it's right?

mapping chdir changes what used to be seen under ftpd as
"/afs/glue.umd.edu/home/elves/lwinc/home" to "/homes/lwinc".
This is actually a good thing as this is what the user sees when using
"telnet" or somesuch. However /homes/lwinc is a symlink to the original
directory before the maping_chdir takes place. It is function of "ls" that
"ls -l <path>", where <path> is a symlink returns something like;

lrwxrwxrwx   1 root     wheel         39 Mar 16 16:57 /homes/lwinc ->
  /afs/glue.umd.edu/home/elves/lwinc/home

This is where the problem occurs. So I added the -L flag so that "ls" would
resolve the symlink. I really need to put some miles on this change before I
could say it "fixed everything". However at least some of my users get their
files again...

Randall

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 16 Mar 1999 20:14:21 -0500 (EST)

On Tue, 16 Mar 1999, Randall S. Winchester wrote:

> ---> LIST /homes/lwinc
> lrwxrwxrwx   1 root     wheel         39 Mar 16 16:57 /homes/lwinc -> /afs/glue.umd.edu/home/elves/lwinc/home
> 
> With the added -L flag:
> 
> ---> LIST /homes/lwinc

This looks like a local 'ls' program problem.  At least the GNU 'ls' on my
Linux box doesn't need -L to behave correctly.  I'll ask a couple of my
Solaris testers to take a look at this; maybe it needs a localization for
Solaris when MAPPING_CHDIR is defined.

> I get the same behaviour with or without "HAVE_GETCWD" defined.

Drat, nothing's ever easy is it?

--

---

From: Alex Yu <[email-masked]>
Date: Tue, 16 Mar 1999 21:01:34 -0500

>> lrwxrwxrwx   1 root     wheel         39 Mar 16 16:57 /homes/lwinc -> 

if you want to show files inside a link dir, just add a "/".
for example, "ls /homes/lwinc/".

alex