Date: Thu, 31 Oct 1996 13:05:31 -0700 (MST) From: Nate Williams <nate@mt.sri.com> To: Mark Crispin <mrc@panda.com> Cc: Nate Williams <nate@mt.sri.com>, chat@freebsd.org Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <199610312005.NAA04328@rocky.mt.sri.com> In-Reply-To: <Pine.NXT.4.00.961031105648.7125A-100000@Ikkoku-Kan.Panda.COM> References: <199610311717.KAA03250@rocky.mt.sri.com> <Pine.NXT.4.00.961031105648.7125A-100000@Ikkoku-Kan.Panda.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
First of all, you initially made the claim that Joe couldn't break into
your system, and that your system had /var/mail was chmod 1777, and that
the user in question didn't have a mbox. Then, you changed your story
to say that /var/mail was 775. Which is the correct story? Unless you
remove *every* program on your system which can create files *OR* you
patch the kernel to not allow any non-allowed to create files in
/var/mail (which means that locks aren't writable and you're effectively
setting things to mode 775), you *aren't* solving the problem.
> 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".
Whoops, sorry. I forgot that w/out the sticky bit you can still remove
folks files.
> > > 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.
This seems like a *heck* of alot of work simply because I want to use
IMAP, which is the only piece of software that doesn't work with the
current setup on my systems. It's less work to fix the IMAP sources,
which I'll do and apparently you're not interested in integrating.
> > > 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.
OK, I was pushing things with mailtool, but it happens to be used alot
by folks locally for some strange reason. :)
> > 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."
You're arguements are the same. You're saying 'You *must* do X to fix
Z', and my response was that 'Y already fixes Z, so why do X which
involve A,B,C,D,E.... Y is a better solution'.
> > 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.
No, as Marc has already been pointed out FreeBSD is in-line with *many*
other unix products, including some commercial versions.
> > 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?
Mail deliver programs *have* to be setuid in the solution you propose as
well (/var/mail 775). The readers don't though since they don't create files.
> What part of "system call locking does not work over NFS" don't you
> understand?
None, what part of 'LOCKING in *any* form doesn't work over NFS' don't
you understand. If it doesn't work, it doesn't work. End of story.
Trying to make it work with other forms is a waste of your time, because
sooner or later it *will* fail.
> 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.
*laugh* So you're the only expert here? "I'm Mark Crispin, and I
understand the problem b/c I've been around for 20 years." Well
'Bunkie', I've been doing administering email and NFS for about 12, so
does that make me 60% as good as you? *grin*
> 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.
My 'kludge' works as well as your given the fact that yours doesn't
work. You've also proven that you don't listen to facts.
#1 - NFS locking doesn't work. You can't make it work, but you can
reduce the window of the race by doing special condition code, but
the race still exists. So, rather than encouraging folks to
*remove* the possibility of corrupted mbox's, you encourage it.
#2 - By attempting to make NFS locking work (it doesn't), you open up
closed holes that require changes to programs outside of the
control of the sys. admin, *plus* it makes for alot more work for
doing normal everyone chores.
Computers are here to make my job easier, not harder. I can choose to
use an easy solution or a hard solution, and I gain nothing by using the
hard solution.
> > "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.
> > 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.
My friends? No, these are folks who *wrote* NFS and programs which do
NFS. And, they know alot more about it than you (obviously).
> 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.
It can't be done reliably.
> 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.
I have a *really* *really* *REALLLLLLLLLY* hard time believing that
given your obvious lack of knowledge.
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610312005.NAA04328>