From owner-freebsd-security Fri Apr 30 7:10:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id DDFCC1590D for ; Fri, 30 Apr 1999 07:10:14 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id KAA20439; Fri, 30 Apr 1999 10:09:36 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 30 Apr 1999 10:09:36 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Pedro J. Lobo" Cc: freebsd-security@freebsd.org Subject: Re: Does mail.local need to be setuid-root? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 30 Apr 1999, Pedro J. Lobo wrote: > Hello, people. > > I have a 3.1-RELEASE machine which, among other tasks, acts as a mail and > telnet server for out students. Recently I noticed that several users were > using more disk space than his quotas should allow (!). After a bit of > investigation, I have traced down the problem to the mail system. > > The problem is that you cand send mail to a user that is over quota, and > the system will append the new message to its inbox (located in /var/mail, > as by default). Indeed, root can append data to a file that belongs to a > user that is over quota. > > As you may see, it is a rather ugly "feature". So, the question is: does > /usr/libexec/mail.local need to be setuid root? Or, alternatively, can I > use /usr/bin/mail as the local mailer? I also administer an alpha with > Tru64 Unix 4.0d and it uses /bin/mail (no setuid/setgid) as the local > mailer. The need to setuid for local mail delivery is necessitated by the placement of user-owned mailboxes in a shared directory. Clearly, there are other possible arrangements that would work and not require the effective uid to be root during mail delivery (for example, individual directories, etc). ACLs would also provide a nice solution. Making mail.local setuid is probably safer than making sendmail setuid, as sendmail has more exposure to the world in the common case. Sendmail currently runs as root, but it's easy to imagine, given capabilities, the ability to get rid of that. Someone was floating patches at one point that modify mail.local to observe file system quotas on the mail spool. I suspect a search on the -questions archive will turn it up. They might have been added to the tree, but for some reason I think they weren't. If the author is still around, they might see a post to -hackers, if not here. If they're decent patches, I'd actually really like to see them committed because I have some machines I'd like to do the same thing on. I personally use the Cyrus mail server instead on my larger mail machines. Cyrus provides all kinds of spiffy functionality (including high-performance POP, IMAP, fine-grained locking on IMAP messages, kerberos support, shared mailboxes with ACLs, a management tool, etc). While it isn't the same as having local mail, it's very similar in many environments, and there are a large and growing number of IMAP readers out there. Cyrus is available in the ports collection, but can also be built cleanly without using the port directly from the CMU distribution (my machines were used for this :). I recommend it highly :). The license allows for free use, but commercial redistribution requires negotiating with CMU for a license. Several companies have negotiated licenses and are selling commercial distributions, if you want support for it. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message