Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker!mit-eddie!rutgers!okstate!minich
From: minich@a.cs.okstate.edu (MINICH ROBERT JOHN)
Newsgroups: comp.sys.mac
Subject: Re: On Location is BAD NEWS!
Message-ID: <5394@okstate.UUCP>
Date: 18 Feb 90 13:46:18 GMT
References: <18045@megaron.cs.arizona.edu>
Organization: Oklahoma State Univ., Stillwater
Lines: 73

In article <17721.635313273@ics.uci.edu>,
truesdel@ICS.UCI.EDU (Scott Truesdell) writes:
>> 
>> Mitch Kapor's new venture sounded like a neat hack.
>> Then I read something in MacWorld, March, 1990, MacWorld News, page
>> 119, right under Mitch's picture that chilled my blood. I quote:
>> 
>> 	"AppleShare volumes also present a curious problem:
>> 	[On Location] indexes don't respect AppleShare's
>> 	security features, so you can't prevent users from
>> 	finding text in folders they are not authorized to
>> 	read. On Technology plans a fix for a later version."
>> 
>> I am NOT a happy camper tonight  :-(
>>   --scott

From article <18045@megaron.cs.arizona.edu>,
by ric@cs.arizona.edu (Ric Anderson):
> 
> If this is true, the real problem is NOT "On Location" or
> MacWorld.  The problem is that there exists a way for an
> ordinary application to bypass file server file protection.

  Wow, wow, wow, hang on a minute, guys. I think something is being grossly
misinterpreted, although the quoted article doesn't help us too much. To access
an AppleShare volume from a network, you just HAVE to have the appropriate
permissions to see the files. There are only a few possible ways I can think of
to get around this, none of which are unstoppable. 

1. On Location is used on the server, creating a handy index that everyone else
on the network can see. Solution: don't put it on the server! If it isn't there,
it can't create an index. Noone can access an index that isn't there! If your
users who want to search for files on the server must use On Location, let
them use it from their Mac and noone will see the index unless it is made
available to everyone else.

2. On Location is used on the server, alowing anyone who uses the server as
a workstation to see files they should not be able to see. Solution: don't 
let people use the server as a workstation. You can't do both at the same time,
and I don't know why you'd be using AppleShare if you only used it part time. 

3. On Location shares information between nodes on the net. (I really doubt this
one. It's just too stupid to go to the effort and not have any protection.) In
this case, I would think that if an individual didn't use On Location, HIS files
would not be revealed to anyone since noone has permissions to see them. (Well,
not unless they are _granted_ permissions :) 

  I think the problem is most likely to be [1] since the [3] would need a lot of
short-sighted work to program and not offer protection of private data and [2]
is a trivial problem.

  Perhaps someone will fully clear this up, since I am NOT familiar with how On
Location works. But I will gurantee this: a program can't access your private
files from somewhere on a network other than a machine which is logged into the
server WITH you logged on to the server, thus effectively granting any program
you run to look at any files you can access. There is no way for a network
program to just call up the server and walk through protected files without 
permission. A program running *ON* theserver is a different matter, but that
shouldn't be a problem with security if you don't RUN the program on the actual
server. Merely having a program stored on the server is not the same as having
the server _running_ the program.

PLEASE do not panic...

Robert Minich
minich@a.cs.okstate.edu

NOTE: I have not used On Location nor do I know exactly how said program works
but I do know about the routines to access an AppleShare file server. (They
are documented in Inside Macintosh V if you must check for yourself.) I can't
take any blame, but I'll be happy to take any credit you might offer.

Have a nice day :-)