Date: Thu, 31 Oct 1996 11:45:34 -0800 (PST) From: Mark Crispin <mrc@Panda.COM> To: Nate Williams <nate@mt.sri.com> Cc: chat@freebsd.org Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <Pine.NXT.4.00.961031105648.7125A-100000@Ikkoku-Kan.Panda.COM> In-Reply-To: <199610311717.KAA03250@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Oct 1996, Nate Williams wrote:
> The directory is 1777 as already stated, but if you pre-create mbox's
> the sticky bit is not really an issue.
You are very mistaken about what the sticky bit does. Read "man 2 chmod".
> > 3) All users must have a mail file on the mail spool.
> > a) This must be done as a consequence of account creation.
> This assumes an 'adduser' shell, which most commercial unices don't
> allow you to customize easily or you have to build from hand. (Solaris,
> SunOS, SCO are known).
Then give this little script to your account creation person and tell them
to run it after running adduser.
----------------------------------Cut Here--------------------------------
#!/bin/sh
# Called with list of users to create mail files
for i in $*
do
touch /var/mail/$i
chown $i /var/mail/$i
chmod 600 /var/mail/$i
done
-----------------------------------Cut Here-------------------------------
> > b) mail readers must not unlink mail files on the mail spool under any
> > circumstances (only very old mailer readers still do this).
> Very modern mail readers do this as well when the box is empty. VM,
> mush, mailtool, etc...
You and I have a different idea of what constitutes "modern" if you
include mailtool.
> You're now getting outside of the scope of the discussion. Most of
> these are *NOT* necessary to get email on a system. If you're
> *paranoid* about email they are good, but if you're paranoid you setup
> the directory 755 and most of the above issues go away simply because
> they "can't happen".
This is a form of false logic called "circular argument".
"You don't need X if you do Y, therefore you must do Y."
> If the mail spool is un-writeable, then the only thing writing to it is
> the system or individual mail-readers, which are all running as the
> user. Assuming the mail readers 'Do the Right Thing', then if the
> mailbox is screwed up it's the users fault.
You miss the point. It has nothing to do with the data in the mail spool,
but rather whether or not mailboxes have proper protections, link status,
and ownership. Even if you protect your mail spool, you still should
undertake periodic security audits in case there was a breach. If you
don't, you are asking for trouble.
> Geeze, I guess that none of us would have ever learned anything. Most
> folks learn by experimenting with things, and what you might consider
> 'cretin' behavior is just someone trying to figure things out.
It is not "experimentation" to go out of one's way to harass other users
with Denial of Service attacks.
> This
> is *beyond* the scope of what the FreeBSD project can do
Then the FreeBSD project should conform to other variants of UNIX. As
matters stand now, FreeBSD stands out as an incompatible and
non-interoperable variant.
> are already fixed in a *much* better way than in your
> proposal, by simply not allowing folks to mess around in /var/mail
> except on their mboxes.
What part of "relying upon setgid/setuid programs is a security risk"
don't you understand?
What part of "system call locking does not work over NFS" don't you
understand?
> It's the *safest* way of doing these steps. You've removed almost all
> of your steps above.
What part of "system call locking does not work over NFS" don't you
understand?
> It's called the 'path of least resistance', and
> most folks who have jobs encourage such behavior.
I have a job, bunkie. That job is to specialize in email, email
protocols, email storage, email spools, and email locking. I've been
doing it for over 20 years.
What I see in front of me are sorcerer's apprentices with a modest
understanding of the issues, inadequate depth, and a personal computer
("everything is on my PC so I don't have to consider heterogenuity")
mindset.
I have been trying, very patiently, to enlighten you to the fact that you
don't have all the answers, and that your kludge doesn't scale.
> "Let's see, I could do 50 tasks to solve the problem, or I could do 1
> task which would remove 45 items from the list. Gee, I think I'll do
> all 50 instead, since I *love* to do lots more work."
"Let's see, I could do a set of several tasks to solve the problem, or I
could do 1 kludge that will sort of work, but will silently fuck over
anyone who uses NFS or who brings in a program that doesn't know that it
should use system call locking. Gee, I think that I'll do the kludge,
since I think that Real Hackers always kludge instead of doing things
right. Those who use NFS deserve what they get"
> *NOTHING* works reliably over NFS. *NOTHING*.
This is the difference between a sorcerer's apprentice and a real hacker.
Sorry, you don't make the grade.
NFS for mail has been made to work. It requires an understanding of what
is and isn't atomic on NFS, and how to interpret NFS error conditions.
NFS doesn't have the same filesystem semantics as a UNIX filesystem, so
you have to implement for NFS semantics and not UNIX semantics.
> You can argue all day with me but both my experience and
> lots of *really* smart folks can prove otherwise.
You don't have very much experience then and/or you or your friends really
aren't as smart as you think you are.
Look, I don't like the idea of mail over NFS either. But I don't lie and
pretend that it can't be done.
I have read the spec. I have spent entirely too much time looking at NFS
kernel source code. I know the people who invented NFS.
> Any kind of NFS locking simply won't work.
Which is why you use .lock files. You can't rely upon O_EXCL, which is
why you use the hard link technique that I outlined in another message.
-- Mark --
DoD #0105, R90/6 pilot FAX: (206) 842-0758 ICBM: N 47.36'24" W 122.34'08"
TOPS-20: A Great Improvement Over Its Successors
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NXT.4.00.961031105648.7125A-100000>