Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!umich!umeecs!zip!spencer From: spencer@eecs.umich.edu (Spencer W. Thomas) Newsgroups: comp.sys.mac Subject: Re: On Location is BAD NEWS! Message-ID: Date: 8 Mar 90 19:06:04 GMT References: <17721.635313273@ics.uci.edu> <10301@asylum.SF.CA.US> <10659@hoptoad.uucp> Sender: news@zip.eecs.umich.edu Organization: University of Michigan EECS Dept Lines: 32 In-reply-to: galen@hoptoad.uucp's message of 7 Mar 90 18:03:13 GMT I probably shouldn't get into this discussion (but I can't resist :-). From my understanding of the way that On Location works, my guess is that it allows you to know 1. The existence of files you can't see, and 2. That those files contain certain strings, but that it does not allow you to actually get at those files. Of course, (2) means you can, with infinite time and patience, eventually deduce the contents of the files. Think about how On Location works: it has 2 parts, a "foreground" piece that you call up and ask to find files containing a particular string, and a "background" piece that keeps the index database up to date. For servers (which is where the problem lies), the background piece runs on the server and therefore has access to all the files. So, all the files end up in the index. The foreground piece runs on your computer, and has access to the index, but not to all the files. To fix this, they have to check the access restrictions when you search the index. This could be done either by trying to access file that the search finds (requires no smarts in the file scanner), or by including information in the index about access rights (requires lotsa smarts in the scanner and a change to the index structure). A third option would be to restrict the set of files the scanner (background piece) is allowed to look at. So, while there is some violation of the access rights, it is not a total bypass, and does not indicate any weakness in the AppleShare access control software. -- =Spencer (spencer@eecs.umich.edu)