NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/infosyst/gopher/1231

Internet Message Format | 1992-11-18 | 1.8 KB

Path: sparky!uunet!ukma!darwin.sura.net!sgiblab!cs.uoregon.edu!news.uoregon.edu!nntp.uoregon.edu!jqj
From: [e-mail] (JQ Johnson)
Newsgroups: comp.infosystems.gopher
Subject: Unix gopherd functionality suggestion
Date: 18 Nov 1992 21:21:38 GMT
Organization: University of Oregon Network Services
Lines: 27
Distribution: world
Message-ID: <[e-mail]>
NNTP-Posting-Host: duff.uoregon.edu

The current Unix gopherd has a notion of a "security file" that restricts
access to the server based on soure IP address or name.  This is a nice
idea, but is somewhat inflexible.  Also, it currently restricts access
only to gopher items of type '0' or 'h'.  For such items, it returns
the "bummer" string instead of the real data.

In addition to not blocking other file accesses (binary downloads, sounds,
etc., it allows some type 1 directory accesses.  There's a bug here though
in the handling of cache files (if a .cache file exists, then type 1
entries are also blocked, but if no .cache file exists then directory
access is not blocked.  This means that the first time a blocked host
displays a directory it may work, but not the second time).

Before I go off and start hacking on the code, I'd like some advice from
the community as to what features are desirable.  My inclination is that
access checks should be for ANY gopher transaction, not just for file
printing.  However, what should the server return in response to a client
request for something random?

More generally, what security model would a typical Unix gopher server
administrator like to be able to enforce?

--
JQ Johnson                Office: 250E Computing Center
Director of Network Services        Internet: [e-mail]
Computing Center, Univ. of Oregon    voice:    [phone]
Eugene, OR  97403-1212            fax: [phone]