From 50b850682e11c0e9f154d3dbdcb3497e96cabc76 Mon Sep 17 00:00:00 2001
From: "Eric S. Raymond" <esr@thyrsus.com>
Date: Thu, 21 Dec 2000 20:38:03 +0000
Subject: Dave Bodenstab's lockfile-acquisition change, and explanation.

svn path=/trunk/; revision=3001
---
 fetchmail.c | 61 +++++++++++++++++++++++++++++++++++++++++++------------------
 1 file changed, 43 insertions(+), 18 deletions(-)

(limited to 'fetchmail.c')

diff --git a/fetchmail.c b/fetchmail.c
index 918ef93c..ef349875 100644
--- a/fetchmail.c
+++ b/fetchmail.c
@@ -574,22 +574,25 @@ int main(int argc, char **argv)
 #ifndef O_SYNC
 #define O_SYNC	0	/* use it if we have it */
 #endif
-    if ((st = open(lockfile, O_WRONLY|O_CREAT|O_EXCL|O_SYNC, 0666)) != -1)
+    if (!lock_acquired)
     {
-	sprintf(tmpbuf,"%d", getpid());
-	write(st, tmpbuf, strlen(tmpbuf));
-	if (run.poll_interval)
-	{
-	    sprintf(tmpbuf," %d", run.poll_interval);
-	    write(st, tmpbuf, strlen(tmpbuf));
-	}
-	close(st);	/* should be safe, fd was opened with O_SYNC */
-	lock_acquired = TRUE;
-    }
-    else
-    {
-	fprintf(stderr,	_("fetchmail: lock creation failed.\n"));
-	return(PS_EXCLUDE);
+      if ((st = open(lockfile, O_WRONLY|O_CREAT|O_EXCL|O_SYNC, 0666)) != -1)
+      {
+	  sprintf(tmpbuf,"%d", getpid());
+	  write(st, tmpbuf, strlen(tmpbuf));
+	  if (run.poll_interval)
+	  {
+	      sprintf(tmpbuf," %d", run.poll_interval);
+	      write(st, tmpbuf, strlen(tmpbuf));
+	  }
+	  close(st);	/* should be safe, fd was opened with O_SYNC */
+	  lock_acquired = TRUE;
+      }
+      else
+      {
+	  fprintf(stderr,	_("fetchmail: lock creation failed.\n"));
+	  return(PS_EXCLUDE);
+      }
     }
 
     /*
@@ -616,7 +619,30 @@ int main(int argc, char **argv)
 	else if (rcstat.st_mtime > parsetime)
 	{
 	    report(stdout, _("restarting fetchmail (%s changed)\n"), rcfile);
-	    execvp("fetchmail", argv);
+	    /*
+	     * Matthias Andree: Isn't this prone to introduction of
+	     * "false" programs by interfering with PATH? Those
+	     * path-searching execs might not be the best ideas for
+	     * this reason.
+	     *
+	     * Rob Funk: But is there any way for someone to modify
+	     * the PATH variable of a running fetchmail?  I don't know
+	     * of a way.
+	     *
+	     * Dave's change makes fetchmail restart itself in exactly
+	     * the way it was started from the shell (or shell script)
+	     * in the first place.  If you're concerned about PATH
+	     * contamination, call fetchmail initially with a full
+	     * path, and use Dave's patch.
+	     *
+	     * Not using a -p variant of exec means that the restart
+	     * will break if both (a) the user depended on PATH to
+	     * call fetchmail in the first place, and (b) the system
+	     * doesn't save the whole path in argv[0] if the whole
+	     * path wasn't used in the initial call.  (If I recall
+	     * correctly, Linux saves it but many other Unices don't.)
+	     */
+	    execvp(argv[0], argv);
 	    report(stderr, _("attempt to re-exec fetchmail failed\n"));
 	}
 
@@ -629,8 +655,7 @@ int main(int argc, char **argv)
 	 * filters out DNS queries over TCP/IP for reasons having to do
 	 * with some obscure kernel problem involving bootstrapping of
 	 * dynamically-addressed links.  I don't understand this mess
-	 * and don't want to, so it's "See ya!" to this hack.
-	 */
+	 * and don't want to, so it's "See ya!" to this hack.  */
 	sethostent(TRUE);	/* use TCP/IP for mailserver queries */
 #endif /* HAVE_RES_SEARCH */
 
-- 
cgit v1.2.3