[comp.emacs] using $HOME/RMAIL.lock as the movemail lock file

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