Date: Mon, 28 Oct 1996 22:47:51 -0800 (PST) From: Mark Crispin <MRC@CAC.Washington.EDU> To: J Wunsch <j@uriah.heep.sax.de>, Ollivier Robert <roberto@keltia.freenix.fr> Cc: current@FreeBSD.org, "Marc G. Fournier" <scrappy@ki.net> Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <MailManager.846571671.12487.mrc@Tomobiki-Cho.CAC.Washington.EDU> In-Reply-To: <199610290635.HAA05491@keltia.freenix.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Oct 1996 07:44:19 +0100 (MET), J Wunsch wrote: > I don't know if that's something imap-related, but i know that this > point regularly comes up: 1777 permissions are in 99.9 % of all cases > wrong in FreeBSD, and they are in general considered a security hole. > (There are exploitable race conditions.) I closed the race conditions at the same time that I made it NFS-safe. > The mailers theirselves use flock() to lock the mailboxes, and gotta > run with root privs anyway. Is there a problem that prevents imap > from being allowed with root privs? imapd logs itself in as the user, and runs with the user's privileges. I avoid writing software that runs with root privileges. The only time I use root privileges is when I need the ability to log in as a user. In such cases, the code which runs as root does nothing other than validate the login as being permitted, then log in as the user and discard root privileges. On Tue, 29 Oct 1996 07:35:54 +0100, Ollivier Robert wrote: > Good. Because this is wrong. Having /var/mail 1777 opens you to various > DoS attacks. For all intents and purposes, these can be closed, while still using 1777. If you can make certain additional assumptions (unfortunately on certain UNIX variants you can't), you can close the denial-of-service attacks entirely. > Having it 755 enables: > - use of fcntl locking, The ability to use fcntl() locking has nothing to do with whether or not the protection of /var/mail is 755. There are several problems with fcntl() locking, including: a) over NFS, it invokes the notorious statd and lockd daemons, which cause cluster-wide locking failures. b) fcntl() does not exist on many BSD variants of UNIX. c) fcntl() locking is not respected by many mail programs. Virtually all programs respect .lock files. flock() locking does not work over NFS at all. imapd uses flock() locking on BSDish systems, and fcntl() locking on SVR4ish systems in addition to .lock files. It issues a warning message if creating the .lock file fails, but then permits the operation. The problem is that if it can't make the .lock file, corrupted mail results when some other program insists upon .lock files and does not check flock()/fcntl(). That is why it does both .lock files and flock()/fcntl(), and why it issues the warning message if it can't make the .lock file. In the past, it quelled the warning on an EACCES error. The result was too many sites with corrupted mail files, particularly on Linux (which adopted the setgid mail religion). Most other mail software assumes setgid mail or even setuid root. imapd assumes neither. > - use of non setgid mailer Say what?? This makes no sense at all. Setgid would use 775. If you really use 755, then you must use a setuid root mailer to write .lock files. Besides the obvious danger of setuid root, this doesn't work over NFS, at least not if you use NFS in a safe way (you don't allow setuid or root access over NFS, do you??). > 1777 has always been wrong. This is absolutely false; on many variants of UNIX it is wrong for it to be anything other than 1777. > It is needed if: > 1- dot-locking is used, > 2- you need to create the folder. > 1- is not a good locking scheme IMO and 2- is not needed because the folder > is created by mail.local/procmail. Whether or not you consider it to be "not a good locking scheme", it is nonetheless the locking scheme used by most variants of UNIX, including most commercial ones. > If imapd needs 1777 it needs to be fixed IMO. This is not going to happen. imapd must support .lock files, hence it needs 1777. > If one use imapd, then one doesn't need dot locking ! That is false. imapd needs to be able to lock against mail delivery, and this means that it needs to create .lock files on most of the UNIX systems in the world. Please hear me out here... We can flame back and forth about this, without reaching any conclusion. Even if you don't agree with my position, at least try to understand it. There is a way for you folks to do what you say you want, just read on. I personally believe that: a) UNIX mbox format sucks b) delivery to a spool directory instead of the home directory sucks c) the .lock file sucks as a locking semaphore d) lock() and fcntl() suck as badly-designed, buggy, and inadequately functional locking system calls. On my own systems, I use a mail file format that is much more efficient and featureful than mbox, with deliver to home directories, with a much more sophisticated locking mechanism that permits simultaneous shared read/write access. I can't believe that anyone would use mbox format on the spool directory except to keep compatibility with the past. But!!! Those beliefs plus $.85 will buy me a cup of coffee on the Washington State Ferries (in other words, these beliefs are worthless). Whatever I may believe, I still have to contend with the old crufy way of doing things. It may be the case that .lock files are not needed on the FreeBSD variant of UNIX, or rather on some systems that run the FreeBSD variant of UNIX. But it is absolutely NOT true on other variants of UNIX, including systems which are much more common than FreeBSD. You can not guarantee to me that I do not need it on other UNIX variants. I know for a fact that such a claim is false. You can not even guarantee to me that I do not need it on a FreeBSD system; it is perfectly possible that a different mail delivery program was installed. Such things have happened. The grim truth is, FreeBSD is a minority system, run by very few sites. It is supported only incidentally; I don't even have a specific FreeBSD port, although there is a BSD, BSDI, and NetBSD port. It isn't that I'm prejudiced against FreeBSD; quite the contrary, I'm a pro-BSD bigot. But the world has chosen SVR4, OSF/1, and Linux. I try to answer all questions, even from the systems that I don't support directly. But, if I have to spend defending myself from flames on something that I really have no control over, it's likely that I will answer future messages from that community's users with "sorry, your OS isn't supported." The bottom line is: 1) No, I will not remove support for .lock files. 2) No, I will not take out support for .lock files under a FreeBSD conditional. 3) No, I will not change the advice about using 1777; this continues to be the recommended configuration for all sites. 4) There *is* a conditional that will quell the error message if an attempt to create a .lock file fails with EACCES. It is not set by default in any port. The FreeBSD hacker community is invited to identify that conditional (hint: it is in env_unix.c), and to pass out instructions on how to build imapd with that conditional set. However, doing so is at that site's OWN RISK, based upon assurances from the FreeBSD hacker community that nothing on the site will depend upon .lock file locking. I don't offer such assurances. I can't. In other words, if the quell conditional is set, it will still attempt to create the .lock files, but it won't complain if it can't. I hope that knowledge of the quell conditional gives us all room in which we can operate. What you can tell your users may be quite different from what I can tell them. What's important to me is that if: a) I get a complaint about corrupted mail b) I find that imapd was built with .lock errors quelled c) I determine .lock files *are* used on on that system after all I can tell the site that they aren't running the recommended configuration and build; that if they had run the recommended build they would have been warned about the non-recommended configuration; that's why their mail files got corrupted; and that their complaint is with whomever told them to use that configuration and/or build. Not me.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MailManager.846571671.12487.mrc>