Subject: Another "can't login" problem

From: Kirke Johnson <[email-masked]>
Date: Mon, 05 Apr 1999 14:02:20 -0700

My problem appears similar to Bruce's, below, but changing ftpaccess from

class   local   real,guest,anonymous *.pcc.edu 192.220.*.* 
class   all   real,guest,anonymous   *

to

class   local   real,guest,anonymous *.*.pcc.edu 192.220.*.* 
class   all   real,guest,anonymous   *

seems to make no difference.  No one can log in, no class errors, but I do find
the
following in syslog:

 FTP LOGIN REFUSED (ftp not in /etc/passwd)

Upgrading to VR17 from wu-2.4-academ, under  HPUX 10.20.  No changes to passwd
files or anything else but inetd.conf, which went from

ftp             stream tcp nowait root /etc/ftpd    ftpd -l -u 022

to

ftp     stream tcp nowait root /etc/ftpd    ftpd -a -d -l -u022

On Tue, 30 Mar 1999, Bruce McCormick wrote:

> I'm trying to upgrade my ftpd from 2.4.2-Beta16 to 2.4.2-VR16 under
> HPUX 10.20. Everything seems to check out ok however no users can
> login. I'm not getting "class" errors in my log, the banner displays
> fine, just can't login any users. Any ideas?

Gregory A Lundberg replied:
>check the syntax of your class statements in your ftpaccess file.  The VR
>version is a bit more critical of subtle errors.  For instance, where the
>following would workunder an academ version (like the beta-16 you were
>running), it won't work under a VR version:

>class users real,guest,anonymous 10.*

>instead, you'll need to be a bit more specific:

>class users real,guest,anonymous 10.*.*.*

----------------------------------------------------------------------
Kirke Johnson                               Internet: [email-masked]
Internet Specialist, ITS , Sylvania Campus      http://www.pcc.edu/
Portland Community College, Portland, OR, USA     (503) 977-4368

---

From: Aaron Holtz <[email-masked]>
Date: Mon, 5 Apr 1999 18:09:57 -0400 (EDT)

Need a thought or direction on this one.  Using the Virtual FTP setup
under BeroFTPD (actually, using the same ftpaccess file as I did for the
newvirt code from time gone by.)  Guest accounts using one of these
virtual FTP servers gets the following when uploading (doing a PUT) on a
file:

ftp> put setvif.pl
local: setvif.pl remote: setvif.pl
200 PORT command successful.
550 Could not determine cwdir: Result too large.

Any real account works fine as does any other command by a guest user.  
The mailing list archives have a few other people with the same error, but
I never found a response/answer.  This is a SunOS 4.1.4 machine.  By going
back to the newvirt code (by just changing the line in /etc/inetd.conf),
everything works.  Any thoughts or pointers are appreciated.

--------------------------------------------------------------------------
Aaron Holtz
ComNet Inc.
UNIX Systems Specialist
Email:  [email-masked]
"It's not broken, it just lacks duct tape."
--------------------------------------------------------------------------

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 5 Apr 1999 18:52:32 -0400 (EDT)

> class all   real,guest,anonymous *

The change I see here is from *.pcc.edu to *.*.pcc.edu

What that means is match host.dept.pcc.edu, but don't match host.pcc.edu
(too few periods in the name).  You probably want to set this back the way
it was.

My comments you quoted were about IP-number wildcards.  If you'd have said
you changes 192.220.* to 192.220.*.* then you'd have made the change I was
discussing.

> seems to make no difference.  No one can log in, no class errors, but
> I do find the following in syslog:
> 

This usually means exactly what it says, there is no user named 'ftp' in
the system /etc/passwd file.  Anonymous login won't work without it.

On some systems, this can mean there's an error accessing the system
/etc/passwd file such as needing to do some hand-waving to tell the system
that _this_ binary is authorized to read the file.

> Upgrading to VR17 from wu-2.4-academ, under HPUX 10.20.  No changes to
> passwd files or anything else but inetd.conf, which went from
> 

Since you didn't have '-a', either you were running an ancient version of
the daemon and were vulnerable to a number of security problems or you
were not using /etc/ftpaccess at all, which would explain why this problem
suddenly seemed to crop up.

I've never seen that the '-d' option does anything even remotely usefull.

The whitespace removal in '-u 022' points to having upgraded from a very
old version of the daemon.

I'd suggest trying the precompiled VR17 binary for HP/UX 10.20 (there are
two, get the right one .. trusted or non-trusted .. for your system).  If
you're building from source, be sure to carefully read through config.h
and src/config/config.hpx to be sure you have selected the options needed
for your platform.

VR17 has been tested and is known to work properly on HP/UX 10.20; so it's
probably a local error either in the compile or configuration.

-- 

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

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 5 Apr 1999 19:18:22 -0400 (EDT)

On Mon, 5 Apr 1999, Aaron Holtz wrote:

> The mailing list archives have a few other people with the same error,
> but I never found a response/answer.  This is a SunOS 4.1.4 machine.  
> By going back to the newvirt code (by just changing the line in
> /etc/inetd.conf), everything works.  Any thoughts or pointers are
> appreciated.

>From a private discussion about this, concerning a VR upgrade:

To: "Steven C. Neighorn" <[email-masked]>
Subject: Re: sunos vr10 problem fix

On Mon, 23 Nov 1998, Steven C. Neighorn wrote:

> The problem is that getcwd does not work properly under SunOS, at
> least in the way it is used now in realpath. I don't remember all the
> details, but I think getcwd is a popen to the pwd cmd and is supplied
> only for backwards compatibility. The getwd command works with the
> surrounding check null terminate code, which you will probably want to
> look at. I don't know if the other machines that have HAVE_GETCWD
> defined also have a problem.

Makes sense.  ISTR something about this problem with SunOS.  You patch
looks good and I'll roll it into VR11 for release on the 1st.  In about 4
days I'll freeze my work on VR11 and roll a test/prebuild tarball and put
it in my prerelease area.

I ran into this problem again, on SunOS, debugging VR16 in March.  At that
time I was able to log into a SunOS 4.1 box and prove, to my own
satifaction, that the program is Sun's runtime is buggy.

First, make sure you're current on *ALL* patches from Sun.

If OS patches for fix this: I don't know how to control this on BeroFTPD,
but what you need to do is convince the source code build system that you
do NOT have getcwd() and it will need to use getwd() instead.  autoconf
will probably detect that getcwd() is there but has no way of knowing that
the operating system's runtime is buggy so be prepared to hack after you
run configure.

--

---

From: Aaron Holtz <[email-masked]>
Date: Tue, 6 Apr 1999 10:10:43 -0400 (EDT)

Greg,

	Thanks for the info - I have this fixed now.  I cheated a bit, but
hey, it works.  To summarize, in order to get BeroFTPD to be happy under
SunOS 4.1.4 and guest 'puts' I did (assuming you are getting the error - 
550 Could not determine cwdir: Result too large.):

1.  Ran ./configure with all the options I needed.
2.  Edited config.cache and change the getcwd line to 'no'
3.  Reran ./configure so it would rebuild src/config.h to undef
	HAVE_GETCWD  and anything else necessary.
4.  Ran make

I had tried undef'ing HAVE_GETCWD in src/config.h at first (as I see the
code has ifdef statements concerning the availability of getwcd) but that
didn't seem to take.  So I did my 4 steps from above and all is good.
Thanks again.

On Apr 5, Gregory A Lundberg molded the electrons to say....