jim@cs.strath.ac.uk (Jim Reid) (05/25/90)
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
rick@uunet.UU.NET (Rick Adams) (05/26/90)
On uunet.uu.net in networking/ftpd.tar.Z is a version of ftpd that works under Dynix (It was developed under Dynix). The only Dynix related problem with it is that ABORTs dont work because Dynix doesnt do the out of band signalling correctly and doesnt support S_OOBINLINE. ---rick
timcc@csv.viccol.edu.au (Tim Cook) (05/26/90)
We are about to connect to AARNet (The Australian Academic and Research
Network), so I wanted to ensure there are as few security holes around as
possible. We have _not_ been supplied new versions of ftpd or sendmail for
our Sequent Symmetry since November 1988, so I have resorted to finding new
versions myself.
I managed to find a newer version of ftpd, but it has problems working
under DYNIX. In its initialization, it goes through the following
statements:
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. Not surprising when you
consider the documentation for this call.
SYNOPSIS
getpeername(s, name, namelen)
int s;
struct sockaddr *name;
int namelen;
DESCRIPTION
Getpeername returns the name of the peer connected to socket
s. The namelen parameter should be initialized to indicate
the amount of space pointed to by name. On return it con-
tains the actual size of the name returned (in bytes).
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)?
Alternatively, has anyone got ftpd source for DYNIX V3.0.12 or later that
has had November 1988's bug(s) removed?
--
Sequent Symmetry -- Nice price, shame about the OS...ianj@sequent.UUCP (Ian Johnstone) (05/27/90)
In article <6230.265d723f@csv.viccol.edu.au> timcc@csv.viccol.edu.au (Tim Cook) writes: >We are about to connect to AARNet (The Australian Academic and Research >Network), so I wanted to ensure there are as few security holes around as >possible. We have _not_ been supplied new versions of ftpd or sendmail for >our Sequent Symmetry since November 1988, so I have resorted to finding new >versions myself. > >...lots deleted..... There have been several maintenance releases of Dynix since Novemeber 1988. There was in particular a security maintenance release that addressed problems in the area that interests you. Either you do not have a service agreement or our records are incorrect. In either case I would suggest you contact Sequent Service sequent!svcmailbug 800-854-9969 (usa only) 503-526-4164 503-526-3731 FAX hope this helps. -- Ian Johnstone uunet!sequent!ianj Sequent Computer Systems 503-626-5700 Beaverton, Oregon
timcc@csv.viccol.edu.au (Tim Cook) (05/30/90)
To all the people who posted and sent me private messages regarding inetd/ftpd/telnetd/DYNIX, thanks. I now have the most recent versions of telnetd and ftpd running from inetd (it looks a bit strange when you telnet to our sequent, and see "4.3 BSD UNIX" in the login banner). For those interested in why we have not seen any DYNIX upgrades since 3.0.12, the blame probably does not lie with Sequent, but with their distributors in Australia, Sigma Data. I'll see what they have to say for themselves.