Article View: comp.sys.novell
Article #7847Macintosh / Netware security hole
From: Paul A Gunderson
Date: Fri, 27 Dec 1991 21:35
Date: Fri, 27 Dec 1991 21:35
46 lines
2907 bytes
2907 bytes
I help administer two networks, a classroom and a general access lab, that have Macintoshes as integral parts. Last August, I upgraded our Netware from v2.15c to v3.11 (with MAC.NLM v3.0). A problem immediately presented itself. All of the Macintosh folders on the server were now wide open! With NW v2.15c, I could assign Read and Open privileges to a folder, thereby allowing the user to access the program files without being able to Search the folder -- actually see what was inside. (I use OnCue -- a menuing program -- to do this. I could configure OnCue once and copy it to each Mac's System Folder. Very simple and effective.) What the user saw on the server was a greyed folder. Yes, it was there, but no, s/he couldn't open it. With NW v3.11, I have problems. File Scan combines Read and Search. I _must_ give File Scan privileges or else the user can't get to the program files. With File Scan OFF, the user doesn't even _see_ the folder. For all the user knows, there is no such folder. With File Scan ON, the folder is wide open. Any and all files are open to the user for any purpose. Unfortunately, Novell has instituted the Apple security bits. And the Apple security bits are, quite frankly, a joke. Neither the Hide nor the Copy Inhibit bits work very well. Yes, the casual point and grab is stopped. But an old copy of MacTools (v7.2 circa 1988) ignores them and copies off the server without breaking sweat. The user is then free to take the program home or whatever. To repeat, with v2.15c, the user couldn't see the program files and thus couldn't copy them. With v3.11, the user has to be a dunce _not_ be able to. So. I have three questions. First, am I missing something obvious? Second, has Novell or Apple instituted some form of copy inhibit that actually stops a copy from the server? (On the IBM side, Novell has Execute Only, etc. that stops this sort of thing.) Finally, has a third party vendor closed this gaping wound? If so, please let me know who and how. Thank you for your attention. Paul Gunderson paulg@convex.csd.uwm.edu Computing Services Division University of Wisconsin - Milwaukee
Technical Details
Message-ID:
<1991Dec27.213522.6835@uwm.edu>Path:
arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!cs.utexas.edu!uwm.edu!convex.csd.uwm.edu!paulgShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fe659,d0e79fe60ab83fbe,start X-Google-Attributes: gidfe659,public X-Google-Thread: 10f035,d0e79fe60ab83fbe,start X-Google-Attributes: gid10f035,public X-Google-ArrivalTime: 1991-12-27 13:44:00 PST Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!cs.utexas.edu!uwm.edu!convex.csd.uwm.edu!paulg From: paulg@convex.csd.uwm.edu (Paul A Gunderson) Newsgroups: comp.sys.novell,bit.listserv.novell Subject: Macintosh / Netware security hole Message-ID: <1991Dec27.213522.6835@uwm.edu> Date: 27 Dec 91 21:35:22 GMT Sender: news@uwm.edu (USENET News System) Organization: University of Wisconsin - Milwaukee Lines: 46 Originator: paulg@convex.csd.uwm.edu