[Top][All Lists]

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

Re: [Nmh-workers] nmh vs mktemp()

From: Joel Reicher
Subject: Re: [Nmh-workers] nmh vs mktemp()
Date: Sun, 06 Apr 2008 15:57:51 +1000

> I've been looking at fixing the various insecure uses of mktemp()
> in the nmh codebase. I've gradually realised that although some of
> them are fixable, some are really very tricky. The trouble is that
> much of the code assumes that you can create a temporary file and
> then later on reopen it by name[*]; and often this happens by a
> very indirect route, with a tempfile name being passed into
> functions which might also be using normal message files. Or we
> might create a tempfile and then rename it to something else.

Firstly, I think this is the sort of work that should not go into 1.3,
but nor should it be held up by the 1.3 release. It's another reason to

> So I think that it might be better to sidestep the whole issue
> by just having nmh create its temporary files in ~/Mail. Because
> this directory isn't writable except by the user, there's no
> danger of malicious attackers creating symlinks in it as there
> is with putting files in /tmp/. Some work would still be
> required, but nowhere near as much.
> Opinions?

If something is going to be fixed, I think it should be fixed properly.
I haven't looked at this part of the code, but would it *really* be
that difficult to change it to passing a file descriptor around instead
of a name? You'll have the compiler's type checking to help with the

If the name of the file is important in a part of the nmh code, then I
would suggest this issue is a result of the fact that any file with a
significant name is not really a tempfile, and should not be created by
mktemp() in the first place.

As to your proposed fix, I think it's just asking for trouble. /tmp is
(almost) guaranteed to be local, which is one of the reasons it exists.
I would not want to see nmh creating tempfiles on a filesystem which could
be NFS mounted (or any other kind of remote file system). There's also the
issue of reading the Path: profile component. I could probably come up
with a few more reasons to believe what you propose is a bad idea.


        - Joel

reply via email to

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