Subject: Strange problem out of the blue

From: [email-masked]
Date: Sat, 18 Feb 1995 22:08:40 -0700 (MST)

Hi,

A couple of days ago our wu-ftpd started to fail on dirs and gets (and
probably all data transfers).  I've poked around to see what changed on
the system, but have come up empty.  If anyone has knowledge of a cause
for the following senario, I'd like to hear about it.  If this is old
hat I appologize, I've been late getting onto this list.

Signon works fine, welcome messsage is diplayed.

pwd	works ok

cd	works ok, message for directory is displayed.

dir	starts out ok, and then chokes.
200 PORT command successful
425 Can't create data socket (0.0.0.0,20). bad file number

Get fails the same way.

--
Mark Walker               UNM/EECE, 7-3688, [email-masked]

         "You can't get there from here..."     -- unknown

---

From: [email-masked] (Russell Street)
Date: Sun, 19 Feb 1995 18:20:12 +1300 (NDT)

> 425 Can't create data socket (0.0.0.0,20). bad file number

I have no idea what causes it, but I found that killing off all ftpds
that are handing around, then HUPing (or killing and restarting
completely) inetd got it flying again.

That was on Solaris 2.3.

Cheers
Russell
 -------------------------------------------------------------------
 Russell Street ([email-masked]) +64 (9) 373-7599 extn 6487
   UNIX Systems Programmer, Computer Centre, University of Auckland
	     http://www.auckland.ac.nz/cc/People/RS.html

	   It's something to do with the shortage of money
	       and the holidays in the South of France.

---

From: [email-masked]
Date: Sun, 19 Feb 1995 20:48:21 -0700 (MST)

>completely) inetd got it flying again.

Me too...  8^(

Thanks Russell.  I should have also included the things I had tried so
far.  I was fairly brutal with various HUPs, TERMs and program restarts
on inetd.  (There was only ever the one ftp session I was playing with
during any of this, and I made sure it had exited each time I tried a
new tack.)  Didn't have much luck, so I crossed my fingers and hoped for
a system glitch.  A reboot didn't help any either.

I'm about to recompile with DEBUG defined to see if I can tell where
things go bonkers.

--
Mark Walker               >  I daydream about fusing two turbocharged
[email-masked]      <  Buick V6s into a V12, and stuffing it into
University of New Mexico  >  a chopped-n-dropped 1953 Buick Super...
Albuquerque, NM           <
505/277-3688 (work)       >          Am I sick, or what?

---

From: [email-masked] (Russell Street)
Date: Tue, 21 Feb 1995 19:04:02 +1300 (NDT)

> a system glitch.  A reboot didn't help any either.

If your problem survives a *reboot* then you really do have something
wrong!

Another tack could be to get a copy of 'lsof' and see just what
processes are holding (0.0.0.0, 20) open.

Personally I would blame the Netscape brower :-) :-) I currently have
unkillable HTTP processes from that wonderful product, plus other
random problems which I am SURE I COULD attriute to it :-)

Cheers
Russell

---

From: Brad Burdick <[email-masked]>
Date: Tue, 21 Feb 1995 12:11:00 -0500 (EST)

> 425 Can't create data socket (0.0.0.0,20). bad file number

We are/were seeing the same (or at least similar problem).  It started around
Sat. (need to review log files to know exact date/time).

Logon and non-data commands work fine.  dir, ls, get, etc all return the 
following error:

200 PORT command successful
425 Can't create data socket (x.x.x.x,20). address already in use

We are running WU-ftpd 2.4(5) on a Sun SPARC 10/514 running Solaris 2.3.

One oddity in this is that netscape was able to access our ftp server just
fine, but ftp clients and mosaic (only other web server I tried) would fail.
Gopher also failed.  Gopher lives on top of our ftp tree, but that is all
they should have in common.

A reboot *fixed* the problem, but we are stilling trying to track down a
cause.

-brad
-- 
Brad Burdick                                      [email-masked]
Internet Multicasting Service, NPB, Suite 1155, Washington, DC 20045
                Under contract from UUcom, Inc.

---

From: Brad Burdick <[email-masked]>
Date: Tue, 21 Feb 1995 12:12:11 -0500 (EST)

> completely) inetd got it flying again.

Tried this on our system (also Solaris 2.3), but it did NOT fix the problem.

-brad

---

From: [email-masked]
Date: Tue, 21 Feb 1995 16:35:29 -0700 (MST)

Russell and Brad had this to offer about our strange problem...

(See Additional Info below for my current exploits.)

>If your problem survives a *reboot* then you really do have something

That was exactly my thinking last Thursday.   8^(

>processes are holding (0.0.0.0, 20) open.

A great suggestion!  (We recently gathered up this amazingly cool program.)
Unfortunately, my efforts were unsuccessful in turning up the culprit.  I
tried several variations on the -i flag like:

	:20
        0.0.0.0:20
        129.24.24.119:20
        <the preceeding with a leading @>
        ftp-data
plus:
        <some other flags like -n and -U>
        <stuff I don't recall>
        <and scaning the whole output by eye>

Any suggestions or advice on how to proceed with lsof would be appriciated!

Brad Burdick writes:
>Gopher also failed.

Sounds like the same problem we have, only yours is temporary.  Hopefully
it stays that way.

Additional Info
---------------

I'm placing additional syslog calls in the code.  Something in the ftpcmd
loop seems to be causing errno to indicate "No such file or directory"
by the entry to dataconn.  This isn't an immediate concern, but does make
me wonder why it's happening.  I'm just now getting up the nerve to modify
ftpcmd.y to find out.
 
I even went so far yesterday morning as to run a separate inetd that only
serviced ftp (after shutting ftp off in my boottime inetd).  I got the
right inetd, but I also still had the 425 problem.

I gathered up the virgin code from wuarchive, same problem.

I'm using gcc 2.5.7.  I get no complaints from the compile.  (OH! There's
the problem! 8)

I disabled the setproctitle (with #undef SETPROCTITLE in src/cinfig.h)
code yesterday because it ps -auxww was generating lines so long grep
was dropping them from the pipeline.  

I'm going to scrutinize the protections and configuration files one more
time tonight.  Tomorrow I'm going to compare with an other local site
(SunOS4) and our backups of the partitions involved.

I'm beginning to believe my signature slogan...

---

From: George Ross <[email-masked]>
Date: Wed, 22 Feb 1995 14:37:12 +0000

> We are running WU-ftpd 2.4(5) on a Sun SPARC 10/514 running Solaris 2.3.

Sounds like bugid 1164519, fixed in 101318-67 and later.
--
Dr George D M Ross, Department of Computer Science, University of Edinburgh
       Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ
Mail: [email-masked]   Voice: +44 131 650 5147   Fax: +44 131 667 7209

---

From: Michael Rice <[email-masked]>
Date: Wed, 22 Feb 1995 09:35:32 -0600 (CST)

> Dr George D M Ross wrote:

I haven't verified the bugid, but the problem is one that is easily solved by
reading the man page for ftpd under Solaris 2.3.  The man page describes how
several files must exist under ~ftp/dev for ftpd to work.  This is true for
wu-ftpd, and was indeed the solution to the exact same problem on my system.

-Michael Rice
 University of Houston

---

From: Brad Burdick <[email-masked]>
Date: Wed, 22 Feb 1995 10:31:16 -0500 (EST)

> Sounds like the same problem we have, only yours is temporary.  Hopefully

Actually, our's turned out to be a known problem with Solaris TCP.  This is
NOT the same as the error you had.  I didn't read it carefully enough when
first responding. :(

[email-masked] writes:

> > > > Hello,
> > > > I am a recent addition to this list. I can give some information probably
> > > > about the problem some people are reporting on Solaris 2.4 (this may not apply
> > > > to stock SVR4 problem reports).
> > > > 
> > > > The only case so far I heared of port 20 being blocked was a SUN running
> > > > OPENWIN (Openwin3.3 on Solaris2.x) and you have to shut down OPENWIN to
> > > > allow the ftp-server function to bind to port 20.
> > 
> > There is one know bug in Solaris 2.4 that affects ftpd (both stock and
> > wu-ftpd) operation. There is patch released for it for Solaris  2.3 but
> > not yet for Solaris 2.4.
> > 
> > The bugid is 1164519 if anyone wants to track it.
> > It happens in a rare transient conditions but the effect is very bad
> > on ftpd operation.
> > 
> > The symptom is that ftp clients will not be able to establish a new data
> > connection (the existing connections will work fine).
> > and the "Can't create data socket..." error is displayed.
> > 
> > [ the symptom above that regular users are able to use but not anonymous
> > is not covered by this bug ]
> > 
> > We are currently in the process of developing the 2.4 patch for it
> > and I will announce it on this list when that is available. Too bad
> > that this bug is there but at this point the best we can do is to
> > make a patch available soon and inform you about it.
> > 
> > The bug causes a TCP endpoint ends up in a bound state when it
> > should not be. ftpd is the only application affected because it is
> > one of the few applications where client end of a connection has
> > requirement of being bound to a specific port number.
> > 
> > The workaround is that the ftpd process that owns that TCP
> > endpoint has to be killed. For busy sites there is no easy way to
> > identify the process(es) that have a particular TCP socket endpoint open
> > so killing all ftpd processes is workaround
> > [ Rebooting accomplishes the same goal ].. Alternatively, looking
> > at "ps -elf | grep ftpd" output and looking for a process running
> > for unusually long time might be another hearistic that can be
> > used to try to kill the right process.
> > 
> > We will soon release the patch to end this problem for good and would
> > appreciate your patience until then.

The fix for this is to apply patch 101318-64 or greater.  We are currently
running 101318-54.  Thanks, Mukesh.

> I'm beginning to believe my signature slogan...

I've expeienced your problem before as well.  Turned out that I didn't have
the correct devices installed for tcp under ~ftp/dev.  You should make sure 
you have the following devices:

crw-rw-rw-   1 root     systems   11, 42 Jan  3  1994 tcp
crw-rw-rw-   1 root     systems   11,  9 Jan  3  1994 ticotsord
crw-rw-rw-   1 root     systems   11, 41 Jan  3  1994 udp
crw-rw-rw-   1 root     systems   13, 12 Jan  3  1994 zero

Major/minor device numbers may, of course, vary.

Since you apparently had a working ftpd before last weekend, not sure what 
might have changed.  Good luck.

-brad

---

From: [email-masked] (Russell Street)
Date: Thu, 23 Feb 1995 18:35:55 +1300 (NDT)

> wu-ftpd, and was indeed the solution to the exact same problem on my system.

I had those devices, but still had the error message above.

Russell

---

From: George Ross <[email-masked]>
Date: Thu, 23 Feb 1995 09:53:51 +0000

> wu-ftpd, and was indeed the solution to the exact same problem on my system.

No, that's a different problem.  It gives almost the same error, except that
it's not "address already in use" (I can't remember what it actually is).

---

From: "Lisa M. Frye" <[email-masked]>
Date: Thu, 23 Feb 1995 07:48:21 -0500 (EST)

> it's not "address already in use" (I can't remember what it actually is).

   Running ftpd setuid root will correct the "Can't create data socket 
(x.x.x.x,20) problem.   

       Lisa Frye                       [email-masked]
       Network Software Specialist     LMS Annex Room 105
       Kutztown University             phone: 610-683-4474
       Kutztown, PA. 19530             fax:   610-683-4634

     "Gossip:  The only thing that travels faster than e-mail."

---

From: [email-masked]
Date: Thu, 23 Feb 1995 13:57:29 -0700 (MST)

The saga continues...

	Thanks to everyone who has provided suggestions.  I still can't
	get rid of the problem though.  I may lose my sanity (what was
	left of it) over this one...  8^)

	I'll apologize now for the length of this mailing.

From: [email-masked] (Mukesh Kacker)
>Here is my attempt to resolve some confusion (I too was confused
>initially). On SOlaris 2.3 and Solaris 2.4 (and SVR4 )installations, there
>have been two very smilar error messages reported and people are
>confusing one for the other often. The message
>    425 Can't create data socket (0.0.0.0,20): Bad file number
>Other messages have suggested this is generated by an incomplete
>anonymous ftp installation (lack of entries for devices ?).
>There is a similar (but not the same error)...something like:
>    Can't create data socket (1.2.3.4,20): Address already in use.
>That is a symptom of a TCP/IP sockets bug (bugid 1164519) in Solaris 2.X which
>shows up rarely at some sites (more often at others) and I had given
>details in and earlier message a few weeks ago. Patches are available for
>Solaris 2.3 [ 101318-68 or later ] and under test for Solaris 2.4 (available
>very soon - will announce on this list).

	We're running -59 of this patch still.  Since real users can
	use the ftp site successfully, I've assumed the problem isn't
	here.  Please let me know if this is a mistake!

From: [email-masked] (Russell Street)
>I had those devices, but still had the error message above.

	I had tcp and zero, and then added udp and ticotsord to no
	avail.  I was short on libraries according to the Sun man page
	for ftpd, to I added all the recommended ones.  Still the
	behavior remains.

	I'm still of the mind that the problem lies in this area
	though.  Here's how things look now.

# pwd
/usr/ftp/dev		# this is ~ftp/dev
# ls -al
total 0
crw-rw-rw-   1 root     sys       11, 42 Oct  7  1993 tcp
crw-rw-rw-   1 root     sys       11,  9 Feb 22 15:31 ticotsord
crw-rw-rw-   1 root     sys       11, 41 Feb 22 15:31 udp
crw-rw-rw-   1 root     sys       13, 12 Oct  6  1993 zero
# ls -al /dev | egrep 'tcp|ticotsord|udp|zero'
lrwxrwxrwx   1 root     root          29 Sep 19 13:29 tcp -> ../devices/pseudo/clone@0:tcp
lrwxrwxrwx   1 root     root          35 Sep 19 13:29 ticotsord -> ../devices/pseudo/clone@0:ticotsord
lrwxrwxrwx   1 root     root          29 Sep 19 13:29 udp -> ../devices/pseudo/clone@0:udp
lrwxrwxrwx   1 root     root          27 Sep 19 13:29 zero -> ../devices/pseudo/mm@0:zero
# ls -alL /dev | egrep 'tcp|ticotsord|udp|zero'
/dev/sr0: No such file or directory		# The CD drive is nolonger
/dev/rsr0: No such file or directory		# here and boot -r is, well...
crw-rw-rw-   1 root     sys       11, 42 Dec 26  1993 tcp
crw-rw-rw-   1 root     sys       11,  9 Dec 26  1993 ticotsord
crw-rw-rw-   1 root     sys       11, 41 Dec 26  1993 udp
crw-rw-rw-   1 root     sys       13, 12 Dec 26  1993 zero

	I have the following libraries (and the links) in place in
	/usr/ftp/usr/lib.  I even created linked from /usr/ftp/lib
	to /usr/ftp/usr/lib just in case.

# ldd /usr/local/etc/ftpd
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libintl.so.1 =>  /usr/lib/libintl.so.1
        libw.so.1 =>     /usr/lib/libw.so.1

From: [email-masked]
>
>I had this problem once when I thought I could use the
>/chroot-path/./cd-path trick in anonymous too. I immedeatly
>got those errors, because for anonymous the wu-ftpd uses
>the whole path as a chroot path. Could it be this one?

	I'm not doing this...  wondered about trying it though.

From: George Ross <[email-masked]>
>it's not "address already in use" (I can't remember what it actually is).

	I should finally be able to look over a level 0 of the two
	partitions involved this evening.  HOPEFULLY, there will be a
	clue there...

From: "Lisa M. Frye" <[email-masked]>
>   Running ftpd setuid root will correct the "Can't create data socket 

	I wondered about this early on, but since inetd thinks ftpd
	should run as root the process should already be uid 0.  I
	tried it anyway, and the result was the same.  I added geteuid
	and syslog calls to verify the seteuid before the socket
	call is working.

        It is by caffeine alone I set my mind in motion,
        It is by the beans of Java that thoughts acquire speed,
        The hands acquire shaking, the shaking becomes a warning,
        It is by caffeine alone I set my mind in motion.
        - Caffeine mantra [Shamelessly ripped off from someone's WWW page]

---

From: [email-masked]
Date: Thu, 23 Feb 1995 20:12:48 -0700 (MST)

Well..., do you want the good news or the bad news first?

The Good News:

	I got another, very simple ftp site up on another Solaris 2.3
	box with little effort.  It's using some of the files off my
	backup tape from the first of the month.

	Very few files were required in ~ftp.  See Appendix A, below if
	you are curious.  The other files involved are shared between
	the systems (on /usr/local/etc).

The Bad News:

	These very same files still have the same old problem on the
	normal ftp site.  I even went so far as to remake the four
	device files in ~ftp/dev since that was the only remaining
	unique aspect of the test site.  Still didn't work though (the
	socket call in dataconn() fails with "No such device or
	address").

	Comparing the ownership and modes from the backup didn't
	turn up any problems.

	These two systems have equivalent system software (/, /usr,
	/opt, ...), and share /usr/local (mounted physically on the
	busted ftp site).

	I'm beginning to worry (again :) about a system compromise.
	Hopefully it was just someone here being all thumbs...  I'm
	making md5 runs against the system files on the two systems
	for comparision purposes.

Tentative Moral:

	Keep those ownerships, permission modes and ftpd configurations
	good and tight for a good night's sleep.  8^)

Appendix A:

# pwd
/usr/ftp
# ll -aR
total 6
drwxr-xr-x  5 root     other         512 Feb 23 19:12 ./
drwxrwxr-x 27 root     sys          1024 Feb 23 18:49 ../
drwxr-xr-x  2 root     other         512 Feb 23 18:49 bin/
drwxr-xr-x  2 root     other         512 Feb 23 18:54 dev/
drwxr-xr-x  2 root     other         512 Feb 23 18:49 etc/
-rw-r--r--  1 root     other         228 Feb 23 19:00 motd

bin:
total 2
drwxr-xr-x  2 root     other         512 Feb 23 18:49 ./
drwxr-xr-x  5 root     other         512 Feb 23 19:12 ../

dev:
total 2
drwxr-xr-x  2 root     other         512 Feb 23 18:54 ./
drwxr-xr-x  5 root     other         512 Feb 23 19:12 ../
crw-rw-rw-  1 root     other     11,  42 Feb 23 18:54 tcp
crw-rw-rw-  1 root     other     11,   9 Feb 23 18:54 ticotsord
crw-rw-rw-  1 root     other     11,  41 Feb 23 18:54 udp
crw-rw-rw-  1 root     other     13,  12 Feb 23 18:54 zero

etc:
total 4
drwxr-xr-x  2 root     other         512 Feb 23 18:49 ./
drwxr-xr-x  5 root     other         512 Feb 23 19:12 ../
-rw-r--r--  1 root     other          14 Feb 23 18:49 group
-rw-r--r--  1 root     other          55 Feb 23 18:49 passwd

You may notice I don't have a usr/lib or an ftp-exec.  These weren't
needed to test ls (NLST) or get (RETR).  (dir (LIST) fails of course.)

      "Trust me, I know what I'm doing."     -- Sledge Hammer

---

From: [email-masked]
Date: Fri, 24 Feb 1995 00:16:00 -0700 (MST)

More late breaking news... (Actually, the solution is contained herein.)

It all boiled down to a bit of gratuitous security enhancement I
did a month and a half or so ago.  I marked several mountpoints as:

			nosetuid

in /etc/vfstab on our anonymous ftp server.  The impact didn't occur
until the next reboot about a month later.

The Sun man page for ftpd mentions that the partition with ~ftp must
*not* be mounted nosetuid.  I, of course, read this more than a few
times; but each time I just wondered why this would be the case.
After all, ftpd is already running with a real uid of 0 by the time
the chroot is used to "reanchor" at ~ftp.

Well, it's too dang-nabbed bad I just didn't check to see if I was
violating the requirement, instead of wondering about the ancestory of
the author of the man page (to whom I am now grateful for such detailed
workmanship 8^).

	Note: We mount another partition on /usr/ftp/pub/dist/.  This
	partition is still mounted nosetuid, and it works fine with
	anonymous ftp.  Go figure...

Oh well, there went one work week down the tubes.  Here's the time line
for this fiasco.

reboot    system boot    Thu Feb 23 22:47 # Oops, I left 'last' off
                                          # 'last reboot | more'.
reboot    system boot    Wed Feb 22 18:28 # Ack!!!
reboot    system boot    Fri Feb 17 15:15 # I'm still caught!!
reboot    system boot    Thu Feb 16 14:41 # I'm caught!
                                          # The trap is armed.
reboot    system boot    Wed Feb 15 00:22 # (unprovoked) system crash.
                                          # The last xfer was at ~2100 Tues.
                                          # I set the trap.
reboot    system boot    Wed Dec 28 15:45

Thanks again to everyone for assistance with my trial!  This is one for
the FAQ.  A script like the one in the Sun ftpd man page might be a
good addition to the wu-ftpd package too.

---

From: [email-masked] (Russell Street)
Date: Fri, 24 Feb 1995 22:11:24 +1300 (NDT)

Hello all.

Very glad to hear you have a resolution.  Still does not explain why I
had the problem with the TCP et al device nodes in place since March
last year. Perhaps my memories were hazy.

> times; but each time I just wondered why this would be the case.

I am *intrigued* by this.  What difference does it make?  nosetuid
means you can't exec programs that are setuid from that file system,
and have the suid bit take effect AFAIK.  It does not affect already
running programs AFAIK.

Or may be it does.  Does it interfer with running programs with
different real and effective UIDs on those file systems?

Under other UNIX systems (such as IRIX) you can mark a file system as
'nodev':

       nodev   access to character and block special files is disallowed.

That would certianly have a LARGE effect on Solaris if existed or is
implied by nosuid.

There seemed to be someone from Sun lurking around this mailing list.
Could I get a clarification? (By private email if you prefer.)

> the chroot is used to "reanchor" at ~ftp.

But it spends its time hoping between root and non-root and all sorts
of messy things like that.

> good addition to the wu-ftpd package too.

Lots of excellent advice is in the 'How to create an Anon FTP' site
FAQ that floats around USENET.  It was posted to this list
sometime. It does cover many OSes, including Solaris 2.3.  It did not
mention nosetuid on filesystems.  Perhaps someone should tell him
about it.

The Solaris man page also has the advice that ~ftp be OWNED BY FTP!
That is real bad news IMHO.  And inconsistent with the way the rest of
the directories are.

Russell

---

From: George Ross <[email-masked]>
Date: Fri, 24 Feb 1995 12:29:17 +0000

> and have the suid bit take effect AFAIK.  It does not affect already

The "nosetuid" also turns off special files (the chroot's /dev entries) as
I recall.
--
Dr George D M Ross, Department of Computer Science, University of Edinburgh
       Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ
Mail: [email-masked]   Voice: +44 131 650 5147   Fax: +44 131 667 7209

---

From: George Ross <[email-masked]>
Date: Fri, 24 Feb 1995 12:46:19 +0000

>    Running ftpd setuid root will correct the "Can't create data socket 

Running it as anything other than root is unlikely to work, but it'll fail for
a different reason to "address already in use" -- EPERM sounds more likely. 
But you don't need to have it setuid as it'll be run as root by inetd anyway.

---

From: [email-masked]
Date: Fri, 24 Feb 1995 09:47:34 -0700 (MST)

>last year. Perhaps my memories were hazy.

Very true, although your experience with HUPping or killing/starting
inetd clearing the problem, would still point to external (to the deamon)
feature/bugs.

>>[...] ~ftp must *not* be mounted nosetuid.  [...]
                  ^^^^^	this stands for?

Me too!  Just before I determined nosetuid was in fact the problem, I
had debug code around the chroot/chdir section of the program.  Here's
what it indicated:

-just tried a socket call before chroot, sockfd: 11; Error 0
-about to chroot/chdir: anonymous 1, guest 0, euid 0; Error 0
-completed chroot: anonymous 1, guest 0; Error 0
-completed chdir: anonymous 1, guest 0; Error 0
-just tried another socket call after chroot, sockfd2: -1;
	No such device or address

After I remounted allowing setuid:

-just tried a socket call before chroot, sockfd: 10; Error 0
-about to chroot/chdir: anonymous 1, guest 0, euid 0; Error 0
-completed chroot: anonymous 1, guest 0; Error 0
-completed chdir: anonymous 1, guest 0; Error 0
-just tried another socket call after chroot, sockfd2: 11; Error 0

>That would certianly have a LARGE effect on Solaris if existed or is

Maybe that's the deal!  SunOS5 doesn't have a nodev option on mount
(that I could find), but the equivalent could certainly be implied by
nosetuid since it's a similar security issue.

>Could I get a clarification? (By private email if you prefer.)

That would be very helpful!  It's mysteries like this that lead
(possibly unfairly) to reduced opinions about system software.

>mention nosetuid on filesystems.  Perhaps someone should tell him

I'll have to look this one up and forward my experiences.

>That is real bad news IMHO.  And inconsistent with the way the rest of

I'd second that.  Our site was partially set up in this fashion, and it
led me to be overly concerned that my problem was caused by an anonymous
ftp user's actions.

	Solely my personal opinions;
		worth even less than you paid for them.

---

From: [email-masked]
Date: Fri, 24 Feb 1995 09:50:17 -0700 (MST)

>The "nosetuid" also turns off special files (the chroot's /dev entries) as

Can you point us to the documentation (that I should have been reading)?  8^)