Date: Fri, 30 Apr 1999 18:08:29 +0200 (MET DST) From: "Pedro J. Lobo" <pjlobo@euitt.upm.es> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Fernando Schapachnik <fpscha@ns1.sminter.com.ar>, freebsd-security@FreeBSD.ORG Subject: Re: Does mail.local need to be setuid-root? Message-ID: <Pine.OSF.4.05.9904301757080.17688-100000@haddock.euitt.upm.es> In-Reply-To: <Pine.BSF.3.96.990430114802.20771A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 30 Apr 1999, Robert Watson wrote: >On Fri, 30 Apr 1999, Pedro J. Lobo wrote: > >> I have looked at the mail.local code, and it does a seteuid(2) to the >> recipient's UID. So, why does the system allow it to write over quota? >> >> I've written a small test program, and have found this: if you seteuid() >> and open a file for writing, write() or fwrite() calls will fail (that is, >> if the effective user is over quota). But, if you open the file, and call >> seteuid() when the file is already open, then you can write as much data >> as you want. As mail.local does this (first opens the user's mailbox, then >> seteuid()'s), the quotas are ignored. >> >> I think this is a bug, and that quotas should be checked (and applied) >> every time you call write() or fwrite() or whatever. Opinions? > >The credentials used to open a file remain bound to the file object. This >is actually very useful, as it means a privileged program can pass access >to a file/whatever using the ancillary data feature, etc. Similarly, a >setuid program can open a terminal device, say, and then change its uid >so that it doesn't have the privilege to open other terminal devices, >but still has the first open. But this is clearly a downside if you later >want to restrict access. Well, that's reasonable. >Presumably the answer is to perform the open that delivers the mail >*after* the setting of the uid. You'll need to also open the file >beforehand to create it if necessary and set ownership, etc. Once you >believe delivery will succeed, reopen the file in the restricted >environment. Have mail.local return some kind of success/fail to the >parent so you can catch race conditions like the user performing rm >/var/mail/user between the check and the reopen. In fact, I've just posted to the list a small patch to mail.local that does exactly that. Maybe it is the right solution, after all. I am also treating EQUOTA errors as *not* temporary, because if they are treated as temporary and the messages are stored in the mail queue there is a (high) risk that /var/spool/mqueue gets full in a few days. I am not sure that this is the right thing to do on all situations, but for me it is (and people keep thinking that having the source code of the full OS can't help. Ha!.) Well, time to go home. See you all on Monday. Pedro. -- ------------------------------------------------------------------- Pedro José Lobo Perea Tel: +34 91 336 78 19 Centro de Cálculo Fax: +34 91 331 92 29 E.U.I.T. Telecomunicación e-mail: pjlobo@euitt.upm.es Universidad Politécnica de Madrid Ctra. de Valencia, Km. 7 E-28031 Madrid - España / Spain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.05.9904301757080.17688-100000>