home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / novell / 11401 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  3.4 KB
  1. Path: sparky!uunet!crdgw1!newsun!novell.com!keith
  2. From: keith@novell.com (Keith Brown)
  3. Newsgroups: comp.sys.novell
  4. Subject: Re: NFS<->NetWare permissions...help!!!
  5. Summary: nfs to netware permissions...help
  6. Message-ID: <keith.12.0@novell.com>
  7. Date: 12 Jan 93 21:52:17 GMT
  8. References: <mtsjej.726857335@gsusgi1.gsu.edu>
  9. Sender: news@novell.com (The Netnews Manager)
  10. Organization: Connectivity Products Division, Novell Inc.
  11. Lines: 47
  12. Nntp-Posting-Host: keith2.sjf.novell.com
  13.  
  14. In article <mtsjej.726857335@gsusgi1.gsu.edu> mtsjej@gsusgi2.gsu.edu (slug) writes:
  15. >NetWare Server----
  16. >Server/GEN:
  17. >        Supervisor       [SRW  M A]                    **I WANT  [SRWECMFA]
  18. >        NoGroup          [   RW          ]                    **I WANT  [                          ]
  19. >        Everyone         [   RW          ]                    **I WANT  [                          ]
  20.  
  21. First point, NOGROUP should not really end up as a group trustee of a 
  22. file/directory when things are configured properly. You should map your UNIX 
  23. groups to NetWare groups using NFSADMIN and initialise your exported file 
  24. systems files and directories to be owned by "proper" mapped groups.
  25.  
  26. Apart from that, what I believe is confusing you is NetWare NFS not removing 
  27. READ or WRITE trustee rights from the group trustee derived from the files 
  28. group owner or the EVERYONE group trustee corresponding to the NFS permissions 
  29. for "other". The reason for this is NetWare NFS's inability to determine 
  30. whether or not these rights actually were put there by itself during some 
  31. previous NFS SETATTR operation. You see, they might have been put there by 
  32. something else on the DOS side and probably for good reason. We are unable to 
  33. make assumptions like that and thus what NetWare NFS giveth in this area
  34. (or what  it may have giveth!), it can not taketh away, just in case! One of 
  35. our axioms for not violating NetWare security with NetWare NFS is that UNIX 
  36. users/groups will only have less than or equal privilege on the NetWare file 
  37. system to the NetWare/DOS users/groups to which they have been mapped. This is 
  38. one of the potential "less than" cases.
  39.  
  40. It actually isn't as complicated as it sounds. If you stick with a UNIX/NFS 
  41. view of the NetWare file system then you will see just that and no confusion 
  42. should result. If you stick with a DOS/NetWare view of the file system then 
  43. you'll see just that, perhaps with more trustees than you're used to seeing 
  44. but what the hey. It's only when you twiddle with things on the UNIX side and 
  45. rush over to the DOS side to see what's happened *or* twiddle with things on 
  46. the DOS/NetWare side and rush over to UNIX to see what's happened that NetWare 
  47. NFS will start messing with your head. To explain what you are looking at 
  48. requires you to have a *complete* understanding of the semantics of both 
  49. NetWare and UNIX/NFS file systems (and I do mean the semantics here. Just 
  50. knowing what r, w and x are on UNIX file systems and what SRWECFMA are on 
  51. NetWare file systems isn't enough. You have to think about what these things 
  52. really mean.). My experience has been that such animals are a tad rare. 
  53. However, rest assured that there is a reason for it all and it's all in the 
  54. name of security! :-)
  55.  
  56. Keith
  57. -
  58. Keith Brown                                        Phone: 408-473-8308
  59. Novell San Jose Development Center                   Fax: 408-473-8990
  60. 2180 Fortune Drive, San Jose, CA 95131               Net: keith@sjf.novell.COM
  61.