Subject: Re: SunOS 4.1.1 wu-ftpd-2

From: Pete Glassenbury <[email-masked]>
Date: Mon, 27 Nov 1995 14:57:29 +1300

> Ok, so you're chowning the files, then trying to write into them as root, 
 > which is mapped to nobody, and losing, right?
 But I don't think it is mapped to nobody --- In my /etc/exports I have
 root=ftpmachine so root has access to write to that machine

 > (which makes sense, you just need to figure out why it's creating and 
 > chowning the files *before* trying to write to them.)
 Just tested to see if it was the writing causing the problem....
 but I could run this and all would work

 /etc/chroot ~ftp /bin/cp incoming/.message incoming/flump

 so again -- I still think it is in the wu-ftpd 

 Anyone have any more ideas on how to narrow this problem down to where
 the problem is.

 Pete
Peter Glassenbury   ([email-masked])
Dept. of Computer Science, University of Canterbury, Christchurch, New Zealand

---

From: Pete Glassenbury <[email-masked]>
Date: Wed, 29 Nov 1995 09:26:46 +1300

> Well, yes, but I didn't say that ftpd was doing something /etc/chroot ~ftp
 > analogous to copy. 
 > Try something more like:
 > /etc/chroot ~ftp /bin/touch incoming/flump
 > /bin/cp incoming/.message incoming/flump
 > 
 > This should at least help narrow down where the problem is.
 > 

 I would think I needed to put the cp inside the chroot so

 created a file fred with 
	#!/bin/csh
	/bin/touch incoming/flump
	/bin/cp incoming/.message incoming/flump

 and, after copying the relavant binaries, ran 

	/etc/chroot ~ftp /bin/fred

 and it all worked -- flump was created and the message copied into it

 I tried with cat instead of cp and chroot still did the correct things
 but since I had changed a couple of things to get these tests to work
 I tried again through ftp --- Still no change 
 Still produces a file with the correct permissions but empty

 -rw-------  1 root            0 Nov 29 09:06 flump

 and still get the message in /var/adm/messages of

 Nov 29 09:06:42 ftphost vmunix: NFS write error 13 on host ourserver fh 746 1 a0000 5fea7 3b5a1bd6 a0000 2 1e0a6aed 

SUMMARY OF TESTS SO FAR

 The real confusing thing is that it is ONLY through wu-ftpd that the 
 problems occur... as root in a shell or as root through chroot
 (and as any other user in shell) things work fine on the ~ftp directories.

 The only workaround I have that leaves things secure (I hope) is to have
 incoming owned by ftp and the owners of files ftp and the mode 0000
 (ftp is the ONLY user that can be used in ftpaccess -- ANY others fail with
 the same error)

 The line out of ftpaccess says

upload  /usr/local/cosc/etc/ftp  /incoming  yes  ftp  staff  0000 nodirs

So I think we are eliminating a lot of the common problems but seem no
closer to solving it

Anyone with any other thoughts??

Pete

---

From: Pete Glassenbury <[email-masked]>
Date: Wed, 29 Nov 1995 09:41:07 +1300

> 
 > So, what was the error clients see again?
 > 
The clients don't see an error !!! 

The clinets see the transfer go through ok (ncftp produces the transfer
statistics as it is transfering and sun ftp shows a sucessfull transfer
with byte counte etc)

The only thing you notice is that is goes through EXTREMELY fast if the
machine isn't loaded (Because it isn't writing anything much to the disk
---- only a one line error message in /var/adm/messages and creating a 
file -- The transfer is like writing to /dev/null

Pete