wu-ftpd not setting home directory correctly

[Debbie Fleith]

The wu-ftpd service has been up and running for years, no updates to the deamon itself. Its on v 2.6.1-24.
We have the following ftp account setup:
hhc:x:732:100:VMMS Scanner:/database/vmms/db/hhdown:/bin/sh
When the hhc account logged into the ftp server a month ago (via a script), it showed the user logging in OK, the home directory set right and a file transfer that traversed up one level worked fine:
Mar 3 11:21:35 vgandj ftpd[11160]: command: PASS password^M
Mar 3 11:21:35 vgandj ftpd[11160]: <--- 230 User hhc logged in.
Mar 3 11:21:35 vgandj ftpd[11160]: FTP LOGIN FROM 10.3.1.18 [10.3.1.18], hhc
Mar 3 11:21:35 vgandj ftpd[11160]: command: PWD^M
Mar 3 11:21:35 vgandj ftpd[11160]: <--- 257 "/database/vmms/db/hhup" is current directory.
Mar 3 11:21:35 vgandj ftpd[11160]: command: TYPE I^M
Mar 3 11:21:35 vgandj ftpd[11160]: <--- 200 Type set to I.
Mar 3 11:21:35 vgandj ftpd[11160]: command: PORT 10,3,1,18,19,48^M
Mar 3 11:21:35 vgandj ftpd[11160]: <--- 200 PORT command successful.
Mar 3 11:21:35 vgandj ftpd[11160]: command: STOR /database/vmms/db/hhup/202010/
CHECK.ME^M
Mar 3 11:21:35 vgandj ftpd[11160]: <--- 150 Opening BINARY mode data connection
for /database/vmms/db/hhup/202010/CHECK.ME.
Mar 3 11:21:35 vgandj ftpd[11160]: <--- 226 Transfer complete
-----
Now, whenever the hhc accout logs into the ftp server, it doesn't show the right home directory, and cannot traverse up one level to send a file and gets this error:
Apr 2 09:35:59 vgandj ftpd[6458]: <--- 230 User hhc logged in. Access restrictions apply.
Apr 2 09:54:03 vgandj ftpd[7294]: FTP LOGIN FROM 10.3.1.18 [10.3.1.18], hhc
Apr 2 09:54:03 vgandj ftpd[7294]: command: PWD^M
Apr 2 09:54:03 vgandj ftpd[7294]: <--- 257 "/" is current directory.
Apr 2 09:54:03 vgandj ftpd[7294]: command: TYPE I^M
Apr 2 09:54:03 vgandj ftpd[7294]: <--- 200 Type set to I.
Apr 2 09:54:03 vgandj ftpd[7294]: command: PORT 10,3,1,18,4,168^M
Apr 2 09:54:03 vgandj ftpd[7294]: <--- 200 PORT command successful.
Apr 2 09:54:03 vgandj ftpd[7294]: command: STOR /database/vmms/db/hhup/202010/CHECK.ME^M
Apr 2 09:54:03 vgandj ftpd[7294]: <--- 553 Could not determine cwdir: No such file or directory.

So, it used to be able to chroot up a level to /database/vmms/db/hhup from its home directory of /database/vmms/db/hhdown -- but now when it logs in, it doesn't show the right home directory, and attempts to send a file to another directory errors.

All file permissions are OK to have the hhc send files to the directory in question.
drwxrwxrwx 7 gbg users 4096 Apr 3 09:24 hhdown
drwxrwxrwx 7 gbg users 4096 Apr 2 09:52 hhup

The wu-ftpd configuration has not changed. What coud the problem be?

[Ivan Ferreira]

That is perfectly normal, as the home directory is:

/database/vmms/db/hhdown

And you chroot to that directory, that becomes "/", so you can't go up.

You must modify your home directory to be:

/database/vmms/db/./

And your scripts to do:

cd /hhup
cd /hhdown

When required.

[Debbie Fleith]

These scripts have been in place for 4 years and they are embedded in scanner software which is not easily changable. Something must have changed that now doesn't allow the script to deposit files where it used to, but wu-ftpd did not change. Any other ideas?

[Ivan Ferreira]

>>> So, it used to be able to chroot up a level to /database/vmms/db/hhup from its home directory of /database/vmms/db/hhdown

That is not possible. Chroot was not working before.

>>> Mar 3 11:21:35 vgandj ftpd[11160]: <--- 257 "/database/vmms/db/hhup" is current directory.

This message means that the user was not chrooted.

>>> Apr 2 09:54:03 vgandj ftpd[7294]: <--- 257 "/" is current directory.

This message means that the user is now chrooted.

You won't be able to go up. What you have to do is to change the home directory to one level up. You can then create symbolik links to avoid changing your scripts.

[Debbie Fleith]

Ok -- so the problem is the server is now change rooting correctly and it didnt before, instead of the other way around. But can anyone tell me what file or files or rpm's would change this feature? I need to know what changed.

[Ivan Ferreira]

In the ftpaccess file, you should have "guestuser/guestgroup" configured, or the ftpd daemon was set to start with the -a option.

[Debbie Fleith]

The /etc/ftpaccess file and /etc/xinetd.d/wu-ftpd has not changed since 2003. Would some other security update, bug fix to some other package could have made the chroot to work now?

[Ivan Ferreira]

Have you only one ftp server installed?

rpm -qa | grep -i ftp
chkconfig --list | grep -i ftp

Do you have the user listed in ftpaccess?