home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.96 / text6640.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  2.0 KB  |  40 lines
  1.     id m0uNJAR-0007tFa; Sat, 25 May 96 07:14 MDT
  2. Sender: owner-executor
  3. Received: from ardi.com by ftp.ardi.com
  4.     (Smail3.1.29.1 #3) id m0uNJ9r-0007tBn; Sat, 25 May 96 07:13 MDT
  5. Path: sloth.swcp.com!tesuque.cs.sandia.gov!lynx.unm.edu!fg1.plk.af.mil!news.zynet.com!imci2!news.internetMCI.com!newsfeed.internetmci.com!solaris.cc.vt.edu!news.mathworks.com!news.kei.com!nntp.coast.net!oleane!jussieu.fr!math.ohio-state.edu!magnus.acs.ohio-state.edu!lerc.nasa.gov!purdue!oitnews.harvard.edu!das-news2.harvard.edu!das-news!kosowsky
  6. From: kosowsky@bellini.harvard.edu (Jeffrey J. Kosowsky)
  7. Newsgroups: comp.emulators.mac.executor
  8. Subject: Re: mounting mac hard disks on E/L
  9. Date: 23 May 1996 20:09:49 GMT
  10. Organization: Division of Applied Sciences, Harvard University
  11. Lines: 18
  12. Message-ID: <KOSOWSKY.96May23160949@bellini.harvard.edu>
  13. References: <KOSOWSKY.96May22101208@bellini.harvard.edu> <uf91ejetku.fsf@ftp.ardi.com>
  14. NNTP-Posting-Host: bellini.harvard.edu
  15. In-reply-to: Clifford T. Matthews's message of 23 May 1996 01:29:05 -0600
  16. To: executor@ardi.com
  17. X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
  18. Sender: owner-executor@ardi.com
  19. Precedence: bulk
  20.  
  21. In article <uf91ejetku.fsf@ftp.ardi.com> Clifford T. Matthews <ctm@ardi.com> writes:
  22. <      Jeff> I know that for other well-defined Linux filesystems such as
  23. <      Jeff> ext2, dos, minix etc, you can use the 'mount' command or
  24. <      Jeff> 'fstab' file to define mounting permissions. Is there a way
  25. <      Jeff> to do this for mac disks to allow them to be user
  26. <      Jeff> mountable/readable/writable by executor?
  27. <
  28. <   No, you can't use mount or fstab to help you out here.  You can change
  29. <   the ownership and/or permissions on /dev/sdb although that can be a
  30. <   bit of a security hole.
  31.  
  32. That does seem to be a bit of a security hole. It also at least to me
  33. seems to be somewhat kludgy. File system access permissions shouldn't
  34. be defined at the /dev/<device> level. (That's why we have
  35. mount... :.)
  36. Will there be a better solution in the future?
  37.  
  38. Jeff
  39.  
  40.