Path: utzoo!yunexus!geac!daveb From: daveb@geac.UUCP (David Collier-Brown) Newsgroups: comp.emacs Subject: Re: using $HOME/RMAIL.lock as the movemail lock file Summary: no, but there's a solution Message-ID: <2779@geac.UUCP> Date: 26 May 88 12:02:12 GMT Article-I.D.: geac.2779 Posted: Thu May 26 08:02:12 1988 References: <11767@duke.cs.duke.edu> <14117@tut.cis.ohio-state.edu> Reply-To: daveb@geac.UUCP (David Collier-Brown) Organization: The Geac "Setuid is Subtle" Department Lines: 48 In article <11767@duke.cs.duke.edu> jwt@tupelo.cs.duke.edu (Jeffrey W. Tannehill) writes: | | When using rmail in gnuemacs v18.51, movemail either uses flock | or it creates a lock file /usr/spool/mail/$USER.lock. In order to do the | latter it has been suggested that movemail be setuid or that it be setgid and | /usr/spool/mail be group writable. I would like to avoid flock because | /usr/spool/mail is remotely mounted (via NFS) on some machines, and for | reasons of paranoia I would like to avoid a set[ug]id movemail altogether. | Emacs is new to me, and I do not know all the"issues" surrounding | its design, so if this suggestion conflicts with the philosophy of emacs | (or good programming :-), please go easy on me. Well, the idea of a setuid/setgid movemail is a teentsy bit kludgy ((:-)), but there really is need for a setuid program... In article <14117@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: | Yes, there are reasons. On systems where locking isn't done by use of | flock, it's done by the creation of /usr/spool/mail/$USER.lock. This | is not a dependency within Emacs; rather, it's a constraint imposed | from without, by the way that /bin/mail delivers. | --Karl As it happens, both movemail and /bin/mail break a basic rule that says: if something needs privilege to do some action, then give it just enough, for only how long it takes to do the action. The two programs need write and delete privilege on that directory for the express purpose of creating /usr/spool/mail/$USER.lock. That implies that one can write an unprivileged movemail and /bin/mail, each of which calls a program that ONLY creates (or deletes) the lock. This new program(s) will have to be setuid/setgid, but it will be trivial to demonstrate that the program(s) do only what it is supposed to do. It should take about 20 lines: 15 or so of checking and about 2 to actually do the task. It will be trivial to show that this is inefficient, too. I suspect that's not a major issue here. --dave (think of it as a "domain of privilege") c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers Ltd., | "His Majesty made you a major 350 Steelcase Road, | because he believed you would Markham, Ontario. | know when not to obey his orders"