home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / next / sysadmin / 4467 < prev    next >
Encoding:
Internet Message Format  |  1992-07-31  |  2.0 KB
  1. Path: sparky!uunet!gatech!rutgers!princeton!ernie.Princeton.EDU!news
  2. From: serge@dadofsam (Serge J. Goldstein)
  3. Newsgroups: comp.sys.next.sysadmin
  4. Subject: Re: re:  Mail.app not reading /usr/spool/mail directory...
  5. Message-ID: <1992Jul31.142321.9321@Princeton.EDU>
  6. Date: 31 Jul 92 14:23:21 GMT
  7. References: <1992Jul27.213307.351@fnbc.com>
  8. Sender: news@Princeton.EDU (USENET News System)
  9. Organization: Princeton University
  10. Lines: 28
  11. Originator: news@ernie.Princeton.EDU
  12. Nntp-Posting-Host: dadofsam.princeton.edu
  13.  
  14. In article <1992Jul27.213307.351@fnbc.com> lemson@fnbc.com (David Lemson)  
  15. writes:
  16. > In article <1992Jul24.133416.2867@bmw.mayo.edu> brunkhorst@mayo.edu (Geoff  
  17. > Brunkhorst) writes:
  18. > > I ran into this last week after blindly believing COPS which
  19. > > told me write access to that directory is considered a security risk
  20. > > (It probably is, but...)
  21. > 
  22. > It's not a risk as long as the sticky bit (that final 't' in the  
  23. > permissions on the listing given by ls -lg) is set.  /tmp should be the  
  24. > same way.  (mode 1777 for you octal fans)
  25. > drwxrwxrwt  3 root     wheel        1024 Jul 27 15:56 mail
  26. > --
  27. > David Lemson                                           (312) 732-4741
  28. > FNBC Sys Admin (Summer) UIUC NeXT Campus Consultant(rest of the time)
  29. > E-mail to: lemson@fnbc.com                          NeXTMail accepted
  30. I also ran into the problem of not making /usr/spool/mail world-writeable.   
  31. What bothered me about this is that Mail did not issue any error messages  
  32. anywhere --- not to the console, not to an Alert panel, not to  
  33. /usr/adm/messages, nowhere.  Here is a premiere application that tries to write  
  34. to  a directory, fails, aborts the requested function, and says nothing at all.  
  35. A very poor show.  Also, adding the sticky bit will certainly prevent users  
  36. from removing files (other than theirs) from the directory, but it will not  
  37. prevent users from adding files to the directory ... in essence, what you've  
  38. done is told your users "forget quotas, if you need disk space, just write to  
  39. /usr/spool/mail".
  40. --
  41. Serge J. Goldstein
  42.