Date: Wed, 30 Oct 1996 14:16:32 -0800 (PST) From: Mark Crispin <MRC@CAC.Washington.EDU> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: terry@lambert.org, j@uriah.heep.sax.de, roberto@keltia.freenix.fr, current@FreeBSD.org, scrappy@ki.net Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <MailManager.846713792.335.mrc@Ikkoku-Kan.Panda.COM> In-Reply-To: <199610302213.QAA26662@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Oct 1996 16:13:36 -0600 (CST), Joe Greco wrote: > Then, who does build their software? The guy who built the a CD-ROM. > Maybe you meant that somebody with a clue builds their software. But > then this would not be a problem. Who has a clue as to whether or not J. Random FreeBSD system, unknown to them, will [n]ever be used in a configuration (such as an NFS mount) where a .lock file is needed? I don't. You don't either. If you say that you have such a clue, you are wrong. The sign of true knowledge is to admit that there are some things that you just don't know. > Now, if you were really interested in a SOLUTION to this problem, rather > than just defending your position on the matter, you would consider a > Configure-style solution. > It should be trivial to figure out, even at run time. It is trivial only to someone who hasn't considered the full implications of the issue. As soon as you do so, it becomes increasingly obscure. > If a system has a mail spool that is mode 0755, you CAN NOT use .lock style > locking: it will not work. Unless the presumption of that system is that anything which access mail files will be setuid root. Surprise! Such systems exists. > IF this is the result of a local > configuration error, it is MUCH more serious than just your one agent. This is precisely why a warning message is output. If this is not the intent, then something is very seriously wrong. > HOWEVER, it is very likely that a system with mode 0755 was set up > specifically because the mail system was engineered to handle that. No, it is very likely that some setup script made this decision, often without the installer's full understanding of the issues. This happens all the time. That is EXACTLY what happened to Marc. > If a system has a mode 0775 mail spool, AND the program has been started > setgid, then you may clearly use .lock style locking, and the system > appears to be suggesting this to you. There is no harm in doing so. Unless the user is running software that she imported herself because the system manager at the Very Big Computer Center is a jerk who won't install anything other than his own favorite mail program. This happens all the time too. Another thing that happens is that the software is not designed to run with privileges, and even depends upon the operating system to determine what files it can access. In either situation, these users need to be warned that there is a problem. > If a system has mode 0775 mail spool and the program has NOT been started > setgid, one could examine the setgid status of /bin/mail (/usr/bin/mail, > whatever the heck) to determine if your agent should be running setgid but > in fact is not. In that case, clearly a warning SHOULD be issued. /bin/mail runs setgid and/or setuid on all systems for reasons unrelated to locking. > Using file locking in all cases is, apparently, at least not harmful, > and could probably be used consistently. I may be incorrect. Then, why the hell are you flaming me? This entire issue is coming up because the user got a warning message, and didn't know why. He has two choices: 1) use the configuration I recommend with 1777, and if necessary take measures to reduce potential denial-of-service problems to irrelvance (this *is* doable!) 2) disable the warning, and take a chance that one day, he will need to do a lock file and can't, and end up with screwed-up data. I tell people to do (1), and point them at how to figure out how to do (2). > So, I remain confused: what is so freaking bad about working out a > Configure-style solution Because the correct configuration/action is not determined at compile time, it is determined at run time for each individual mailbox! If you try it, and it works, you probably needed to do it. If you try it, and it doesn't work, the answer is "either don't do it, or the system is incorrectly configured" and you don't know which (and I explained why you can't look at /bin/mail to find out). There ain't any good answers here. The only safe thing to do is "try 'em all; if you get back an error, report the error unless you've been told to quell the error reports." It used to be that the default was to quell the warning. That default may be right for you, but that default has been proven WRONG for hundreds of other systems that I've had to help fix. This came about thanks to various "security check" scripts floating around the network. The correct configuration of those systems was a public spool, set up as noted above. Mail delivery used .lock files, not system call locking. Without the system manager's knowledge (or, more commonly, his understanding), the "security check" script "fixed" the protection of the spool. The mail readers couldn't make a .lock file, and since the error message was quelled they didn't complain. After all, they could apply a system call lock. So, for several months, they had periodic complaints of lost mail or corrupted mail files, and couldn't figure out why. Many of these sites didn't have source code to their mail delivery program either. So much for the site knowing what sort of locking to use. > GEEEEEZ. It's not rocket science to do this stuff. No, it's crystal ball. You don't know all the answers. Nobody does. The moment that you realize this will be your moment of satori. To someone who's been dealing with this damn problem for over two decades, it is extremely irritating to deal with people who think they know all the answers. In terms of your snide remark about "rational argument", that's what creationists say about scientists on the subject of evolution. Just like creationists, you insist upon saying "but all you have to do is assume X and then Y must be this way". If X is flawed, then you can't use it. Your arguments rest upon certain false hypotheses: a) It can be known at build time what locking protocol to use. b) All files are accessed using the same locking protocol. c) It can be known, if a locking protocol fails, whether or not it is a true locking failure which must be reported. d) All instances of a particular operating system work the same way. The issue on the table is: How do you lock a mail file, when there is uncertainty about the locking protocol used by the agent that delivers to that mail file, uncertainty about the identity of the agent that delivers to that mail file, and uncertainty about the constancy of either of these over time? Observations: There are two major forms of locking, lock files and system calls. Some programs do both. The result of doing either unnecessarily is wasted effort. The result of failing to do either when it was necessary is eventual trashing of a mail file. You know when a lock file fails; you get an OS error. If it was necessary, the error should be reported. If it was unnecessary, the error should be ignored. A system call lock either fails over NFS, or involves a fragile mechanism that sometimes causes a cluster-wide hang. Most expert option is to eschew doing a system call lock over NFS. The right way to lock may be one mechanism on one file, and a completely different mechanism on another file. One way this can happen is when heterogenous environment NFS is involved. Additional requirements: Produce a plug-and-play binary, or at least sources that don't ask questions that J. Random Loser can't answer. Work properly today, and also tommorrow even when something new is pushed at it (such as an NFS mount to a mail spool on a system OS). Be safe rather than sorry.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MailManager.846713792.335.mrc>