🚀 go-pugleaf

In article <1992Jul27.213307.351@fnbc.com> lemson@fnbc.com (David Lemson)  
writes:
> In article <1992Jul24.133416.2867@bmw.mayo.edu> brunkhorst@mayo.edu (Geoff  
> Brunkhorst) writes:
> > I ran into this last week after blindly believing COPS which
> > told me write access to that directory is considered a security risk
> > (It probably is, but...)
> 
> It's not a risk as long as the sticky bit (that final 't' in the  
> permissions on the listing given by ls -lg) is set.  /tmp should be the  
> same way.  (mode 1777 for you octal fans)
> drwxrwxrwt  3 root     wheel        1024 Jul 27 15:56 mail
> --
> David Lemson                                           (312) 732-4741
> FNBC Sys Admin (Summer) UIUC NeXT Campus Consultant(rest of the time)
> E-mail to: lemson@fnbc.com                          NeXTMail accepted
I also ran into the problem of not making /usr/spool/mail world-writeable.   
What bothered me about this is that Mail did not issue any error messages  
anywhere --- not to the console, not to an Alert panel, not to  
/usr/adm/messages, nowhere.  Here is a premiere application that tries to write  
to  a directory, fails, aborts the requested function, and says nothing at all.  
A very poor show.  Also, adding the sticky bit will certainly prevent users  
from removing files (other than theirs) from the directory, but it will not  
prevent users from adding files to the directory ... in essence, what you've  
done is told your users "forget quotas, if you need disk space, just write to  
/usr/spool/mail".
--
Serge J. Goldstein