From: jml4@cus.cam.ac.uk (John Line)
Newsgroups: comp.infosystems.gopher
Subject: UNIX gopherd 1.03 - non-chroot gid & ftp problems. Also, RFC931 query.
Date: 5 Nov 92 21:28:21 GMT
Organization: U of Cambridge, England

I am just setting up an experimental gopher server to demonstrate that it
could provide the facilities we need, and have encountered a few problems
which I hadn't tripped over with brief test sessions in the past. This is
with gopherd 1.03 on SunOS 4.1.2.

(1) Running from inetd, non-chroot, I have told it to run as user "gopherd",
which works fine, but a colleague involved in setting up the system config
file changes asked what happened to the group. The answer seems to be that
it inherits "wheel" as the group, and nothing is done to change it... This
implies that while the non-chroot gopherd is prevented from having root access
to files, ill-advised links from the data directories could still let it have
excessive access to group wheel files.

Is this the security risk that it appears, and an oversight, or totally
irrelevant? If it ought to be fixed, does anyone have patches for gopherd 1.03
to allow an overriding group to be specified on the gopherd command line? [OK,
shouldn't be difficult to invent from scratch.]

(2) Someone mentioned a week or two back that the gopherd ftp gateway facility
seemed to leave junk files in /tmp, but I haven't noticed any followups. Is
there a simple solution for this? Not a major problem during testing, but it
would be a real pain in a live server. When does it happen (i.e. what provokes
it), if it doesn't simply happen for all files (and directory listings).

(3) The temporary files created by the ftp gateway get created with rw
permissions for all classes of access. This implies scope for modification in
transit (or at least, malicious corruption in transit). I presume it's the same
problem of inheriting an unhelpful default protection mask that makes it
inadvisable to use ftp "put" to copy files (because they end up with rw
protection for all categories).

I'm starting gopherd via a shell script because of inetd's limitation on the
number of arguments that can be passed to daemons, so I can probably fix it
with a umask call before running gopherd (not tried yet), but should gopherd
include some defensive coding to get around this? (An "officially
editable"/documented #define for the locally-preferred mask?)

Oh, and

(4) an afterthought - we're just looking at RFC 931 identification of who is
at the far end of a TCP connection (it seems to be seeing a new lease of
life as an "identification" protocol, after failing miserably as an
"authentication" protocol). Has anyone added RFC 931 lookup to identify who
is calling gopherd (if the client system supports RFC 931 lookup) and adding
the information to the log file? [Yes, this does raise privacy issues, but
I expect I'll get asked about it, if we decide to go wholeheartedly with
RFC 931 to improve audit-trail information for network connections.]

                                John
-- 
John Line - Cambridge University Computing Service, Computer Laboratory,
            New Museums Site, Pembroke Street, Cambridge CB2 3QG, ENGLAND.
Internet: jml4@cus.cam.ac.uk  JANET: jml4@uk.ac.cam.cus  Phone: +44 223 334708