Bug#526614: fdm dies trying to deliver via | sendmail

[Frank Terbeck]

I will _not_ go ahead and ask for an upload to stable without this
patch being tested. And since the original reporter backed out before
doing that...

Anyway, I'll attach the patch provided by Nicholas - tweaked a little
to work with quilt - to this message. Anyone who wants to test it, is
welcome to do so. Instructions on how to use additional patches with
the debian fdm package can be found here:
http://ft.bewatermyfriend.org/fdm/trypatches.html

Regards, Frank
Fix a problem when checking if a setuid program is running using kill().
See #526614 for details.

Index: fdm-1.5/command.c
===
--- fdm-1.5.orig/command.c	2009-05-08 10:42:41.0 +0200
+++ fdm-1.5/command.c	2009-05-08 10:44:47.0 +0200
@@ -134,9 +134,10 @@
 
 	/* XXX Check if the child has actually started. */
 	if (kill(cmd->pid, 0) != 0) {
-		if (errno != ESRCH)
+		if (errno == ESRCH)
+			CMD_DEBUG(cmd, "child not running");
+		else if (errno != EPERM)
 			fatal("kill");
-		CMD_DEBUG(cmd, "child not running");
 	}
 
 	/* Parent. */

Bug#526614: fdm dies trying to deliver via | sendmail

[Frank Terbeck]

Nicholas Marriott :
> Yes, it is probably because it is setuid. fdm calls kill(pid, 0) to see if the
> process has actually started. This isn't actually needed, it is a debugging
> aid. In any case, if it gets EPERM it is probably safe to assume the process
> does exist. Please try this diff:

Ian, since I didn't hear from you again I suppose you require
assistance in trying the diff Nicholas provided.

See .

There's a link to an extended debian patch against
fdm_1.5.orig.tar.gz, which is also available from there.

Which those you can build a debian package that includes said patch.

Since (from your initial report) you seem to be on a i386 machine, you
can also use the .deb provided there, here is a quick link:
  

Note, that this a not a properly updated package yet. It currently
only includes the new patch in addition to the old package. No updated
documentation, no nothing. We need to make sure it fixes the problem
and doesn't break anything before attempting to touch 'stable'.

Please try it and report back.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#526614: fdm dies trying to deliver via | sendmail

[Frank Terbeck]

[ Ccing the fdm-users mailing list. Please reply to all addresses in ]
[ To: and Cc: in order to keep all involved parties and the debian   ]
[ BTS in the loop.   ]

Ian Zimmerman :
> Package: fdm
> Version: 1.5-3
> Severity: normal
> 
> I tried to make fdm deliver directly to sendmail (exim actually) with a config
> line like this:
> 
> action "default" pipe "/usr/sbin/sendmail -oi -odi i...@localhost"
> match all action "default"
> 
> but i get this in the log:
> 
> May  2 00:35:01 matica fdm[7686]: fatal: cmd_start: kill: Operation not 
> permitted
> May  2 00:35:02 matica fdm[7675]: fatal: main: child socket closed
> May  2 00:35:02 matica fdm[7676]: fatal: fetch_poll: parent socket closed
> May  2 00:35:07 matica fdm[7678]: fatal: child_deliver: privsep_send error
> 
> and .fdm.lock stays around :-(
> 
> I reverted to the grotty fetchmail way (SMTP to localhost) and that works.
> Maybe it has something to do with exim being setuid root?

Since I don't use any pipe actions myself, I'm clueless here.

Is this something that was addressed since fdm 1.5 was released? Are
there any workarounds?

Regards, Frank



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#526614: fdm dies trying to deliver via | sendmail

[Nicholas Marriott]

Yes, it is probably because it is setuid. fdm calls kill(pid, 0) to see if the
process has actually started. This isn't actually needed, it is a debugging
aid. In any case, if it gets EPERM it is probably safe to assume the process
does exist. Please try this diff:

Index: command.c
===
RCS file: /cvsroot/fdm/fdm/command.c,v
retrieving revision 1.53
diff -u -p -r1.53 command.c
--- command.c   1 Apr 2008 21:02:22 -   1.53
+++ command.c   4 May 2009 14:37:04 -
@@ -140,9 +140,10 @@ cmd_start(const char *s, int flags, cons
 
/* XXX Check if the child has actually started. */
if (kill(cmd->pid, 0) != 0) {
-   if (errno != ESRCH)
+   if (errno == ESRCH)
+   CMD_DEBUG(cmd, "child not running");
+   else if (errno != EPERM)
fatal("kill");
-   CMD_DEBUG(cmd, "child not running");
}
 
/* Parent. */


On Mon, May 04, 2009 at 03:33:26PM +0200, Frank Terbeck wrote:
> [ Ccing the fdm-users mailing list. Please reply to all addresses in ]
> [ To: and Cc: in order to keep all involved parties and the debian   ]
> [ BTS in the loop.   ]
> 
> Ian Zimmerman :
> > Package: fdm
> > Version: 1.5-3
> > Severity: normal
> > 
> > I tried to make fdm deliver directly to sendmail (exim actually) with a 
> > config
> > line like this:
> > 
> > action "default" pipe "/usr/sbin/sendmail -oi -odi i...@localhost"
> > match all action "default"
> > 
> > but i get this in the log:
> > 
> > May  2 00:35:01 matica fdm[7686]: fatal: cmd_start: kill: Operation not 
> > permitted
> > May  2 00:35:02 matica fdm[7675]: fatal: main: child socket closed
> > May  2 00:35:02 matica fdm[7676]: fatal: fetch_poll: parent socket closed
> > May  2 00:35:07 matica fdm[7678]: fatal: child_deliver: privsep_send error
> > 
> > and .fdm.lock stays around :-(
> > 
> > I reverted to the grotty fetchmail way (SMTP to localhost) and that works.
> > Maybe it has something to do with exim being setuid root?
> 
> Since I don't use any pipe actions myself, I'm clueless here.
> 
> Is this something that was addressed since fdm 1.5 was released? Are
> there any workarounds?
> 
> Regards, Frank
> 
> --
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> ___
> fdm-users mailing list
> fdm-us...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fdm-users



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#526614: fdm dies trying to deliver via | sendmail

[Ian Zimmerman]

Package: fdm
Version: 1.5-3
Severity: normal

I tried to make fdm deliver directly to sendmail (exim actually) with a config
line like this:

action "default" pipe "/usr/sbin/sendmail -oi -odi i...@localhost"
match all action "default"

but i get this in the log:

May  2 00:35:01 matica fdm[7686]: fatal: cmd_start: kill: Operation not 
permitted
May  2 00:35:02 matica fdm[7675]: fatal: main: child socket closed
May  2 00:35:02 matica fdm[7676]: fatal: fetch_poll: parent socket closed
May  2 00:35:07 matica fdm[7678]: fatal: child_deliver: privsep_send error

and .fdm.lock stays around :-(

I reverted to the grotty fetchmail way (SMTP to localhost) and that works.
Maybe it has something to do with exim being setuid root?

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.29.2matica2 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash-minimal

Versions of packages fdm depends on:
ii  adduser  3.110   add and remove users and groups
ii  libc62.7-18  GNU C Library: Shared libraries
ii  libpcre3 7.8-2   Perl 5 Compatible Regular Expressi
ii  libssl0.9.8  0.9.8g-15+lenny1SSL shared libraries
ii  libtdb1  1.1.2~git20080615-1 Trivial Database - shared library
ii  zlib1g   1:1.2.3.3.dfsg-12   compression library - runtime

fdm recommends no packages.

fdm suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org