[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] outstanding patches

From: Harald Geyer
Subject: Re: [Nmh-workers] outstanding patches
Date: Fri, 20 May 2005 21:53:06 +0200

Hi Oliver!

Sorry, I'm late on this:

> Debian patches
> 1 & 3    : man page links/sections; Debian specific, I think

Well, I feel the Debian policy actually makes some sense, but
I have no idea what other people do/need ...

> 6 (143485) : "#define vfork fork" on linux. Should be harmless enough

I see you have already committed that patch. I believe this was a
bad idea: It seems you haven't got the point of the bug - I'm not
sure whether the Debian maintainer did.

The problem is that under linux you shouldn't modify any data between
vfork and exec*. nmh doesn't care about this. For example it calls
functions which set errno and thus lead to strange messages from the
parent process.
Although this appeared as minor message bug, it is quite serious because
vfork seems to be used carelessly throughout the whole code. It might
even be a security issue, if somebody figures out how to overwrite
important data (eg on the stack).

Debian just did "#define vfork fork" in mh.h, because this was the
quickest solution and they don't need to care about portability across
unices (except for bsd) and the like.

But this is not what we want for the following reasons: The issue is not
restricted solely to linux. I've just read the vfork manpages of AIX
ans solaris and it seems to be the same there.
Also we don't want to write such things in mh.h. Actually it's the
job of the auto* tools to manage the features of different systems.

I believe there are three approaches to fix this:
 * Fix the code, so that it can use vfork without harm. This is
   a lot of work and I'm not sure it is possible to do that at all.
 * Generally replace vfork with fork in the code. This could be done
   within minutes (just grep and edit), but we would first need to make
   sure, that this doesn't break on some system somebody cares about.
 * Figure out which systems have the same issue as linux and do some
   autoconf magic to do a "#define vfork fork" based on this.

Any opinions on that?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]