Subject: VR13/VR14 open issues

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 17 Feb 1999 11:48:48 -0500 (EST)

A lot has been happenning over the past few days with wu-ftpd and the VR
versions.  So much so, in fact, that I'm afraid that I may let things slip
through the cracks.  So here's what comes to my mind as the currently open
issues needing resolution.  If you've raised an issue which isn't on here
and which hasn't been resolved, let me know.  This email is as much to
help me keep organized as it is to you the chance to ensure I'm not
forgetting your problem; if it appears I have, send me a personal note.

SunOS 4.1
---------
This is probably another problem with NFS.  I'll be researching this on a
4.1 system to try to figure out what the particular site has done to
tickle a bug in fb_realpath().  With VR13 the daemon confuses the client.
With VR14 the error is ignored and everything _appears_ correct.  I want
to try to figure out what exactly is being ignored and try to really fix
it.  The ftpadmin on the testbed machine is claiming an additional problem
which appears to be FAQ-ish about bin/ls doing the wrong thing, a quick
check didn't show what he reported; I'll be looking into this later today
when he gets into his office.

HPUX
----
A signal (SIGBUS?) kills the daemon during login while trying to set the
umask to the site-default value.  A patch was submitted to me personally
today, which I forwared to the list.  I am awaiting reports as to whether
this actually solved the problem.  It was localized to the umask by
hard-coding the default umask rather than using the ftpaccess/command-line
values.

AIX
---
There's something going on in the throughput limiting code which is either
preventing compilation or crashing the daemon.  I don't have any AIX
access, but what I've seen on the list leads me to believe someone who
does will have a good, general solution shortly.  Frankly, I expect it'll
turn out to be another size mismatch like the HPUX problem.

SunOS 4.1
---------
It seems some of the compiler/runtime on the system don't define RAND_MAX.
The value of RAND_MAX is critical to the code trying to fight PASV port
stealing.  Right now, I've got a suggestion to hardwire a value of 32767
(0x7FFF) in the src/config/config.s41 file; but I question if that's known
to be the correct value (it's the value in one of the runtimes is all I
know for sure).

All platforms
-------------
The IP-wildcards on the class clause were changed.  I've got a workable
solution and have had what may be a better one proposed.  One of them will
be in VR15.  Until then, the workable patch is available on-request but I
recommend switching from wildcards to IP/CIDR or IP:NETMASK notation
instead.

In general, considering the thousands of new VR users over the past week
or so, the number of problems has been quite low, and I'm very pleased.
I've received as many notes telling of a successful drop-in replacement as
I have received asking for help (at least for non-FAQ issues).

-- 

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

---

From: John-Paul Pagano <[email-masked]>
Date: Wed, 17 Feb 1999 11:59:30 -0500

>forgetting your problem; if it appears I have, send me a personal note.

I guess one issue I've had, although I'm not really sure if it amounts to a
bug or a simple lack of proper documentation, is my recent inability to get
the following ftpaccess file directives to do anything useful:

lslong
lsshort
lsplain
lsreal

Does anyone out there have definitive experience with getting these
directives to work?

--
John-Paul Pagano
Unix Systems Administrator
Voice: (212) 208-0828
Fax: (212) 825-1040

---

From: Ayamura Kikuchi <[email-masked]>
Date: 18 Feb 1999 03:04:22 +0900

> to be the correct value (it's the value in one of the runtimes is all I

It may be better we use a value of 2147483647 as the value of RAND_MAX.
That of 32767 (0x7FFF) is too small on SunOS4.

-- ayamura

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 17 Feb 1999 16:01:28 -0500 (EST)

> That of 32767 (0x7FFF) is too small on SunOS4.

On thinking about the risks of guessing, and unless someone else comes up
with an authoritative answer, I'm inclined to go with Ayamura Kikuchi's
suggestion of using 2147483647 for RAND_MAX on SunOS4.  Guessing too small
means overrunning an array which could be disasterous.  Guessing too large
turns the randomization functions back into a (near?) linear search.  I'd
rather see the deamon vulnerable on SunOS4 than go bonkers when it
overruns the array.

Ayamura: my current testing roll for VR15 has the 32767 value in it.  I'll
be changing the definition and adding #ifndef protection for the #define.

-- 

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

---

From: Aris Yannopoulos <[email-masked]>
Date: Thu, 18 Feb 1999 15:36:18 -0500 (EST)

VR14::Solaris-2.6

The machine in question has to be real only (no anon, or guests).

Is there a way to make it refuse anonymous logins completely?  Right now
what happens is it says:

331 Guest login ok, send your complete e-mail address as password.

but because they are not in ftpaccess it doesn't let them in.  Any way to
just have it refuse them with just the name?

	Ari(=

  -= Madness is not an illness... it's a privilege... =-

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 18 Feb 1999 15:53:07 -0500 (EST)

> just have it refuse them with just the name?

Sure.  Edit config.h to

#define HELP_HACKERS

then `./build clean ; ./build sol` will re-enable all kinds of stuff like
you're looking for.

--

---

From: Aris Yannopoulos <[email-masked]>
Date: Thu, 18 Feb 1999 15:54:34 -0500 (EST)

> #define HELP_HACKERS

Nope, I just realized that it is ignoring them even though they are in
ftpusers :(

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 18 Feb 1999 16:13:04 -0500 (EST)

On Thu, 18 Feb 1999, Aris Yannopoulos wrote:

> To clarify I just want the forbidden users from ftpusers to be denied
> without even asking for a password.  Users not def'd in ftpusers
> should be authenticated normally (ie whether they exist or not should
> just return a normal failure)

Yeah, HELP_HACKERS is what you want to enable.

--

---

From: Aris Yannopoulos <[email-masked]>
Date: Thu, 18 Feb 1999 16:22:12 -0500 (EST)

> Yeah, HELP_HACKERS is what you want to enable.

Wouldn't that also do it for any user as well (not just those in
ftpusers?)

	Ari(=

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 18 Feb 1999 16:43:57 -0500 (EST)

> Wouldn't that also do it for any user as well (not just those in

The HELP_CRACKERS option re-enabled the old way of handling login
failures.  If a bad username was given, it failed immedeately with a
message to that effect.  If the username was listed in ftpusers, it said
so.  If a bad password was give, it told you that as well.  This is the
way beta-18 and all prior versions of wu-ftpd worked.

with VR14, when you #undef HELP_CRACKERS (the default) all this is
modified.  The daemon behaves the same right up to the point where a
password would let you in.  The it kicks you out, for whatever reason,
with a single message that does not indicate _why_ you're being kicked
out.  Maybe you entered a unknown username, or you tried to login as root,
or you typo's your password.

The idea is to make it harder to tell what usernames exist on the ftp
server. Anonymous ftp usesthe username 'ftp' and is treated just like
anyone else under this scheme.

--

---

From: Aris Yannopoulos <[email-masked]>
Date: Thu, 18 Feb 1999 15:56:07 -0500 (EST)

To clarify I just want the forbidden users from ftpusers to be denied
without even asking for a password.  Users not def'd in ftpusers should be
authenticated normally (ie whether they exist or not should just return a
normal failure)

---

From: Tom Lieuallen <[email-masked]>
Date: Thu, 18 Feb 1999 17:41:07 -0800

> hard-coding the default umask rather than using the ftpaccess/command-line

I had problems compiling with HP's C/ANSI C compiler (not bundled with
the OS) before applying the patch.  With the patch that was previously
posted, this compile works as it should.  The binary even works -- a
bonus.  :-) I haven't tested it thoroughly, but it has solved
the obvious problems.

As for feedback -- I could not get gcc 2.8.1 to create a usable binary
for HPUX 10.20.  The compile succeeds without complaint (even before
the patch, I believe), but the binary is not very functional.  Real
users can authenticate just fine and do the basic commands.  However,
anonymous users are kicked out as soon as they attempt 'ls'.  The
following is a sample message from syslog:

Feb 18 17:15:50 myhostname ftpd[6143]: USER ftp
Feb 18 17:15:51 myhostname ftpd[6143]: PASS toml@
Feb 18 17:15:51 myhostname ftpd[6143]: SYST
Feb 18 17:15:51 myhostname ftpd[6143]: TYPE Image
Feb 18 17:15:52 myhostname ftpd[6143]: PORT
Feb 18 17:15:52 myhostname ftpd[6143]: TYPE ASCII
Feb 18 17:15:52 myhostname ftpd[6143]: LIST
Feb 18 17:15:52 myhostname ftpd[6143]: exiting on signal 11

The ~ftp directory tree is the same as I was using for beta-15
and also works fine for beta-18-vr14 when compiled with HP's C compiler.
So, I don't think it is an issue with my 'ls' binary or missing
libraries.

I'm going to run with the HP C compiled version, so this isn't urgent
for me -- but someone else might have the same problem.  (Or I could
have done something stupid.)  :-)

thank you

Tom Lieuallen
Oregon State University

---

From: Aris Yannopoulos <[email-masked]>
Date: Sun, 21 Feb 1999 16:19:54 -0500 (EST)

I have a server set up to have only real users by ftp.  I set the
following in ftpaccess:

chmod           yes     real
delete          yes     real
overwrite       yes     real
rename          yes     real
umask           yes     real

Still, none of the users can overwrite or delete files.  What am I doing
wrong?

	Ari(=

---

From: Gregory A Lundberg <[email-masked]>
Date: Sun, 21 Feb 1999 18:47:36 -0500 (EST)

On Sun, 21 Feb 1999, Aris Yannopoulos wrote:

> Still, none of the users can overwrite or delete files.  What am I
> doing wrong?

There's not enough to know why but as a guess, I'd say either the users
are not 'real' but 'guest', or the permissions on the files and/or
directories containing them are preventing the overwrite/delete.  The
exact error message seen at the client end should tell you if it's a
permissions problem.

--

---

From: Alex Yu <[email-masked]>
Date: Sun, 21 Feb 1999 19:40:12 -0500

>delete          yes     real

Dir permission.

Alex

---

From: Aris Yannopoulos <[email-masked]>
Date: Mon, 22 Feb 1999 13:24:04 -0500 (EST)

> exact error message seen at the client end should tell you if it's a
Actually here is the error:
553 pick_of_seven.java: Permission denied. (Delete)

and there are no guests, all users are real.  The permissions on the
directory would allow a write by the user (since I can create the file)
and the t bit isn't set so there is no issue there.

	Ari(=

---

From: Alex Yu <[email-masked]>
Date: Mon, 22 Feb 1999 13:41:55 -0500

>directory would allow a write by the user (since I can create the file)

first, does real user have permission to delete the file?  are all your
real users in the same group?  is the file chown by the group where they
belong to and have rw permission?  it is not the ftpd problem.  you have to
work on file permission.

alex

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 22 Feb 1999 13:59:20 -0500 (EST)

> 553 pick_of_seven.java: Permission denied. (Delete)

Either the line quoted in your original message isn't the one you're
actually using, or the one you're actually using has a subtle typo in it
(look for non-printing chars), or the user attempting to delete
pick_of_seven.java wasn't a real user, but was a guest or anonymous users
instead.

Look in the ftpaccess file for other delete clauses which could be taking
effect instead of this one.

check that you're actually using the ftpaccess file you think you are.

--