Date: Thu, 31 Oct 1996 12:16:11 -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: <MailManager.846792971.5917.mrc@Ikkoku-Kan.Panda.COM> In-Reply-To: <199610312005.NAA04328@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Oct 1996 13:05:31 -0700 (MST), Nate Williams wrote: > 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. It is very simple. This has nothing to do with what I do on my system. I don't use a mail spool. Mail spools are stone knives and bearskins. I described, for comparison purposes, three different configurations: /var/mail at chmod 1777. /var/mail at 775 with setuid/setgid /var/mail at 755 and system call locks. I compared each on their strengths and weaknesses. Why is the concept of comparison difficult to understand? Are Americans really as poorly-educated and illiterate as I have been led to believe? > 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. That is bullshit. The software works. The only question is whether or not to quell a warning message. > It's less work to fix the IMAP sources, > which I'll do and apparently you're not interested in integrating. I doubt that you use the software. And no, I am not going to screw 99% of the market for you. > 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'. Y fixes Z only if you define a critical component out of Z. In this case: X ::= procedures to make a public mail spool safe from DoS attacks Y ::= mail spool protected 755, system call locking only Z ::= mail spool reasonably safe from DoS attacks possibly accessed over NFS (and NFS server may be non-FreeBSD) not require privileges on mail reading programs In order for Y to fix Z, you must define "possibly accessed over NFS" out of Z. I have stated, many times, that this is not acceptable. Now, let's consider what Linux and some SVR4 systems do: Y' ::= mail spool protected 775, group mail, mail readers run setgid. In order for Y' to fix Z, you must define "not require privileges on mail reading programs" out of Z. Next, we consider X. When all of X's conditions are satisfied, this solves Z. Finally, if we add a condition of "must not be complex" to Z, then neither X, Y, nor Y' solve for Z. You have to do something completely different, such as deliver to home directories. Delivery to home directories is what the real hackers do. Spool directories are stone knives and bearskins. > No, as Marc has already been pointed out FreeBSD is in-line with *many* > other unix products, including some commercial versions. SVR4 does not use system call locking. That is the overwhelming bulk of the market. OSF/1 does not use system call locking. Linux does not use system call locking. Two dozen BSD variants which I have surveyed do not use system call locking. BSD on VAXen used system call locking before NFS support was added, and apparently now FreeBSD does. This is much of a market. > Mail deliver programs *have* to be setuid in the solution you propose as > well (/var/mail 775). I don't propose 775. I gave 775 as the example of what SVR4 and Linux do. In a public mail spool, mail delivery programs run as the user that they deliver to. No privileges at all. > None, what part of 'LOCKING in *any* form doesn't work over NFS' don't > you understand. How much do you want to wager on this point? I wager $100 that I can write a "locked open" and "locked close" routine that will work over NFS, and that you can not write a main program that will demonstrate its failure. You are allowed to use the following system file calls: read(), write(), ftruncate(), fstat(), as well as output to stdout (in other words, you aren't allowed to cheat by analyzing the locking mechanism and deliberately sabotaging it). > I've been doing administering email and NFS for about 12, so > does that make me 60% as good as you? *grin* 1984, yeah, that's about when the current crop of foolish kids started coming in. > #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. I dare you to show the race in the hard link technique that I outlined. I don't think that you can. Enough people have stared at kernel code and concluded that there is no race if you do this. > #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. It is much more work to tell people who have used NFS access for years that they are no longer allowed to so do because some guy at SRI says it doesn't work. > My friends? No, these are folks who *wrote* NFS and programs which do > NFS. Such as? Be careful. I know the guys who invented NFS, from the time that they were my student users at the Stanford Computer Science Department. I also work with the guys who develop it today at SUN.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MailManager.846792971.5917.mrc>