jwt@tupelo.cs.duke.edu (Jeffrey W. Tannehill) (05/24/88)
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 writeable. 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. Has anyone considered having movemail create a lock file in $HOME/RMAIL.lock instead of in /usr/spool/mail/$USER.lock? Are there any reasons why this shouldn't be done? 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. jwt /*______________________________Jeff Tannehill_______________________________* * MAIL: Duke Dept. of Computer Science ARPA: jwt@cs.duke.edu * * Durham, NC 27708-2591 USA CSNET: jwt@duke * * PHONE: +1 919 684 5721 UUCP: decvax!duke!jwt */
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (05/25/88)
jwt@tupelo.cs.duke.edu writes:
Has anyone considered having movemail create a lock file in
$HOME/RMAIL.lock instead of in /usr/spool/mail/$USER.lock? Are there any
reasons why this shouldn't be done?
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
daveb@geac.UUCP (David Collier-Brown) (05/26/88)
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"
mike@ists (Mike Clarkson) (05/28/88)
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 writeable. 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. How paranoid do you have to be of movemail sgid (2755) daemon, and /usr/spool/mail group writeable (775)? Do people see problems with this? > Has anyone considered having movemail create a lock file in > $HOME/RMAIL.lock instead of in /usr/spool/mail/$USER.lock? Are there any > reasons why this shouldn't be done? It won't work unless you can get /bin/mail to write lock files there too. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
dieter@nmtsun.nmt.edu (Dieter Muller) (05/28/88)
In article <2779@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes: >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. > > The two programs need write and delete privilege on that directory >for the express purpose of creating /usr/spool/mail/$USER.lock. Ok, so what's wrong with making /usr/spool/mail group "mail", and making movemail setgid "mail"? As long as no users get put into that group, I don't see the problem about giving too much power. I'm interested because I'm in the process of bringing up 18.51 right now. Our current solution (for 18.46), has been to make /usr/spool/mail world-writable, with the sticky bit set. Under SunOS 3.5, this means only the owner of a file can diddle with it (mv, rm, etc., unless of course you're root). It almost seems like just having that sticky bit would be enough, since the mail files themselves are owner-only privs (0600). Comments? Dieter Muller -- You want coherency, cogency, and literacy all in one posting? Be real. ...{cmcl2, ihnp4}!lanl!unm-la!unmvax!nmtsun!dieter dieter@nmtsun.nmt.edu