Re: [exim] Side effect of the fix for CVE-2010-2023

On 2010-06-12 at 15:47 +0100, Dr Andrew C Aitchison wrote:
> I often have multiple names for a mail folder (though more for
> use from my MUA than from my .forward) and appendfile doesn't
> allow delivery to a symbolic link (at least by default - there is
> the private option allow_symlink). With this change it doesn't deliver
> to a hard-linked folder either, which means that the user has to
> specify the unique real name of a folder in any .forward file.

What are you doing about locking? Use of "<filename>.lock" is not going
to reliably lock when multiple filenames map to the same file.

What about "if the directory is only writable by the owner, which is the
owner of the file, then ignore multiple hardlinks if either
use_fcntl_lock or use_flock_lock is set"? Would that be sufficient?

> I presume that all of the sticky bits, plus group and other write
> bits clear would be sufficient ?

Sticky bit is irrelevant, I think we'd just require that (variable names
invented):
((file_stat->st_uid == directory_stat->st_uid) &&
((directory_stat->st_mode & 0222) == 0200))

> (At least on systems which forbid hardlinked directories

Shouldn't be an issue: the multiple links would share the same inode and
thus the same ownership.

> I think we are safe to assume that the parent directory is the
> one that could be vunerable to attack ?)

Not quite. Say you are delivering to:
/var/foo/mail/mailbox

If "foo" is globally writable and does not have the sticky bit set, then
someone could move aside "mail" and replace it. That would be a stupid
setup.

So I'm inclined to say that we should add a new option for this case,
"permit_multilinked_file" or somesuch? And if that option is set,
require that we also have a locking mode which locks the inode contents,
rather than based on naming conventions in the filesystem, else panic
for misconfiguration.

Thoughts?
-Phil