Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!strath-cs!baird!jim From: jim@cs.strath.ac.uk (Jim Reid) Newsgroups: comp.sys.sequent Subject: Re: Wanted: Secure version of ftpd(8) for DYNIX Message-ID: Date: 25 May 90 11:53:28 GMT References: <6230.265d723f@csv.viccol.edu.au> Sender: jim@cs.strath.ac.uk Followup-To: comp.sys.sequent Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland. Lines: 34 In-reply-to: timcc@csv.viccol.edu.au's message of 25 May 90 22:58:22 GMT In article <6230.265d723f@csv.viccol.edu.au> timcc@csv.viccol.edu.au (Tim Cook) writes: addrlen = sizeof (his_addr); if (getpeername(0, (struct sockaddr *)&his_addr, &addrlen) < 0) { syslog(LOG_ERR, "getpeername (%s): %m",argv[0]); exit(1); } addrlen = sizeof (ctrl_addr); if (getsockname(0, (struct sockaddr *)&ctrl_addr, &addrlen) < 0) { syslog(LOG_ERR, "getsockname (%s): %m",argv[0]); exit(1); } There are other socket-type calls with `0' as first argument contained in the code, but it dies on the getpeername(2) call. Now nothing is done to file descriptor 0 before these calls are attempted, so it is also unsurprising that ENOTSOCK is found in errno. What the hell is supposed to happen here (thinking that this must be a case of changed behaviour in 4.3bsd)? Like most of the network daemons in 4.3 BSD, ftpd is not started at boot time. Instead, the inetd super-server is started. It listens on several sockets and hands off incoming connection requests to the appropriate daemon. For instance, a connection to TCP port 21 will make inetd start up an ftpd to handle the request. The daemon for ftp or whatever started through inetd gets its standard input, output and error output (file descriptors 0, 1 and 2) tied to the socket inetd was listening on. Thus, the ftpd will already have the local socket on file descriptors 0, 1 and 2 when it starts. If it doesn't, ftpd wasn't started from inetd properly. Jim