Re: saving attachement fails on sshfs filesystem
I suspect that this is indeed related. Actually, a similar problem
exists for the vfat file system.
What happens for vfat is this: In order to create a file safely,
mutt creates a temporary directory that it believes it controls [is
that assumption really valid for vfat?], and creates the file in
there. Mutt then needs to move the file one level up.
It appears that, in doing so, we have successfully reduced one
impossible problem (safely creating a file) to another one (safely
moving/renaming a file): To move a file safely, we have for ages
used link(2) and unlink(2), since rename(2) is unsafe on NFS.
Unfortunately, link(2) will fail on file systems that don't support
hard links.
Now, the mutt code even tries to be clever about this, by detecting
EXDEV and falling back to rename(2) in that case -- according to a
comment in safe_rename(), we once made an assumption that file
systems that react with EXDEV to a link(2) that we believe is
guaranteed to be within a single file system can be trusted to do a
proper rename(2), presumably based on the assumption that we're
actually dealing with Coda.
Just to make it all a bit funnier, vfat seems to return EPERM when
you try to invoke link(2), which is not a condition that we seem to
be able to usefully evaluate or react to.
So, we're now caught in a catch-22: We can create our files
super-securely, and in the course of doing so stop creating files on
file systems that don't support hard links, or we can start taking
the risk that the creation of files in shared directories is subject
to race conditions at least in some use cases. (Note that we use
safe_fopen even for files in locations that are derived from user
input.)
Input welcome.
--
Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
On 2007-01-02 16:07:40 +0100, Louis-David Mitterrand wrote:
> From: Louis-David Mitterrand <vindex+lists-mutt-dev@xxxxxxxxxxx>
> To: mutt-dev@xxxxxxxx
> Date: Tue, 2 Jan 2007 16:07:40 +0100
> Subject: saving attachement fails on sshfs filesystem
> X-Spam-Level:
>
> Hello,
>
> Using debian unstable's 1.5.13-1.1 I can no longer save attachements on
> a sshfs (fuse) partition: pressing <enter> at the save-file prompt makes
> mutt wait a few seconds after which the same prompt and default filename
> returns with no error message. Instead of saving the file mutt creates a
> .muttxxx directory for each attempt:
>
> drwx------ 1 ldm ldm 6 2007-01-02 15:31 .mutt7mnbhX/
> drwx------ 1 ldm ldm 6 2007-01-02 15:25 .muttKXRT83/
>
> Might this be related to this recent change (debian bug #396104)?
>
> CVE-2006-5297:
> Race condition in the safe_open function in the Mutt mail client
> 1.5.12 and earlier, when creating temporary files in an NFS
> filesystem, allows local users to overwrite arbitrary files due to
> limitations of the use of the O_EXCL flag on NFS filesystems.
>
> CVE-2006-5298:
> The mutt_adv_mktemp function in the Mutt mail client 1.5.12 and
> earlier does not properly verify that temporary files have been
> created with restricted permissions, which might allow local users to
> create files with weak permissions via a race condition between the
> mktemp and safe_fopen function calls.
>
> See
> http://marc.theaimsgroup.com/?l=mutt-dev&m=115999486426292&w=2
> for details.
>
>