home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ukma!darwin.sura.net!sgiblab!cs.uoregon.edu!news.uoregon.edu!nntp.uoregon.edu!jqj
- From: jqj@duff.uoregon.edu (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: <1eec52INNjfe@pith.uoregon.edu>
- 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: jqj@ns.uoregon.edu
- Computing Center, Univ. of Oregon voice: (503) 346-1746
- Eugene, OR 97403-1212 fax: (503) 346-4397
-