From owner-freebsd-current Wed Oct 30 14:16:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04566 for current-outgoing; Wed, 30 Oct 1996 14:16:38 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA04558 for ; Wed, 30 Oct 1996 14:16:30 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA26662; Wed, 30 Oct 1996 16:13:36 -0600 From: Joe Greco Message-Id: <199610302213.QAA26662@brasil.moneng.mei.com> Subject: Re: /var/mail (was: re: Help, permission problems...) To: MRC@CAC.Washington.EDU (Mark Crispin) Date: Wed, 30 Oct 1996 16:13:36 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, terry@lambert.org, j@uriah.heep.sax.de, roberto@keltia.freenix.fr, current@FreeBSD.org, scrappy@ki.net In-Reply-To: from "Mark Crispin" at Oct 30, 96 10:56:37 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > On Wed, 30 Oct 1996 08:51:27 -0600 (CST), Joe Greco wrote: > > Has it ever dawned on you that if you were to make this sort of policy > > decision bubble up to the surface via a Configure-like mechanism, in the > > manner that Elm does, that this would completely solve your problem? > > No, this won't. Most people who have systems and install software do not know > what an fcntl is. Most people who have systems and install software don't > even build their own software. Then, who does build their software? Maybe you meant that somebody with a clue builds their software. But then this would not be a problem. 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. THINK about what I am saying: If a system has a mail spool that is mode 0755, you CAN NOT use .lock style locking: it will not work. Not only IMAP but also Elm and other mail agents WILL NOT be able to lock the mailboxes. IF this is the result of a local configuration error, it is MUCH more serious than just your one agent. HOWEVER, it is very likely that a system with mode 0755 was set up specifically because the mail system was engineered to handle that. 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. 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. If a system has mode ?777 mail spool, you may clearly use .lock style locking. Using file locking in all cases is, apparently, at least not harmful, and could probably be used consistently. I may be incorrect. So, I remain confused: what is so freaking bad about working out a Configure-style solution that: 1) Gets the mode on ${mailspooldir} 2) Gets the setgid status of ${systemdefaultmailprogram} 3) Compares them using the above matrix, and 4) Compiles your agent appropriately? I would prefer that it actually ASK the user, after having set the defaults appropriately, but I am not going to argue trivial details. GEEEEEZ. It's not rocket science to do this stuff. I haven't been naive enough to expect my code to compile identically on all boxes using the same paradigms for the better part of a decade. > If you are smart enough to know what the right answer is to "use fcntl or lock > file", and understand all the implications of that decision when your system > is in a heterogenuous NFS cluster, then you are smart enough to know how to > look at the code and find the compile-time option to turn off a warning > message. Yes, I agree. So for the rest of the world, you want to print a confusing and potentially worrisome message because their more sophisticated and modern UNIX system does not conform to your idea of How The World Must Work? I'm lost as to why that must obviously be correct. I've been building software under many UNIX variants for many years. All the good packages attempt to make as many reasonable guesses as possible about their environment. This generally allows an administrator to pull the software out of the tarball, glance at README/INSTALL, maybe type "sh Configure" or somesuch, and then type "make; make install". Since this whole thread was started when Marc Fournier (who - as far as I can tell - is a very competent systems administrator) ran into this problem, it appears that your assertion that ""If you are smart enough to know what the right answer[...], then you are smart enough to know how to look at the code and find the compile-time option to turn off a warning"" is just not true. > Do you even use the software in question? If not, then shut up and leave the > discussion to those who have a stake in the question. I've been dealing with mail systems, issues, and implementations for years. I apologize if I didn't make that clear. I've also been around long enough to recognize your name as someone who is rather unlikely to be swayed by rational argument and modern configuration practices. So please do not bother responding to this message, since I know you think that I am wrong. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968