$TMPDIR (was Re: Security: Mutt and mailcap rules)

[Derek Martin]

On Sat, Jun 29, 2019 at 03:09:57AM +0200, Vincent Lefevre wrote:
> > I think you missed my point.  How does Mutt KNOW /tmp is OK?  What if
> > it is not on your system?
> 
> /tmp is standard and assumed to be usable (see POSIX, Chapter 10).
> A system without /tmp is broken.

Which in no way prevents such systems from existing, or running Mutt.

> > I gave the example of Windows...
> 
> which is not POSIX. Windows may need some changes in the Mutt source
> (not just concerning /tmp).

Sure, if that's a stated requirement, it's fine.  But with your idea of
treating everything other than /tmp differently from /tmp, you're
creating a rule that starts out having an exception case, and it's
been my experience that those cause systems to be prone to unexpected
faults, or at least configuration confusion, time and time again.
There's no need for it.

> > > because some random user could have created /var/tmp/$USER first
> > > (note: I want something under /var/tmp for Mutt, but the usual
> > > temporary directory under /tmp, hence the use of Mutt's $tmpdir
> > > variable).
> > 
> > This isn't a problem, except that you need to decide  what to do when
> > it happens.  In such a case your mkdir will fail, and you will have to
> > resort to some back-up plan.
> 
> which is why I use /var/tmp. It's guaranteed to work.

How's that?  It has the exact same semantics as /tmp.  On a multiuser
system, someone could log in after a reboot and create
/var/tmp/vincent and you're in exactly the same boat.

> > > > FWIW, I was speaking about $TMPDIR specifically, and generically (i.e.
> > > > not specific to Mutt, though inclusive of Mutt).  If you set $TMPDIR,
> > > > you don't need to set $tmpdir,
> > > 
> > > That's not true: one may want a different location for Mutt. A reason
> > > can be that one generally wants the usual temporary directory under
> > > /tmp because it is cleaned up on reboot (if decided by the admin),
> > 
> > Why?  As you point out, /tmp is cleaned up only on reboot.
> 
> That's the issue with Mutt: if the machine reboots while I'm
> writing a mail, I don't want to lose the message.

As I said in part of the message you snipped, if you don't run tmpfs,
you don't have this problem.  Most users probably don't need it and
shouldn't run it, and would benefit more from the relative permanence
of conventional scratch space.

> > No competent admin will reboot the system on you without giving you
> > some time to clean up what you're doing
> 
> Silly remark. Machines get rebooted because of (temporary) power
> outage (happens quite often) or because they crash (happens quite
> often too). That's the real world.

Hardly silly.  The argument here is A) in the context of not using
tmpfs, as I said, and B) in the context of multi-user systems.
They're generally on UPS.  They won't lose power without shutting down
cleanly, and without tmpfs you won't ever have your files deleted on
you due to a crash.  Perfectly non-silly.

But seriously, I've used and/or managed such systems for the last 25+
years, from college to present, and I think the number of times I've
seen a stable production system crash I could count on my fingers.  If
I lost PART of a message I was typing once every three years, I would
not even imagine this was a problem I needed to solve.  You can get
yourself a small UPS for your desktop, or write your e-mail on a
laptop, which I'd be a little surprised if you weren't already doing
anyway.

I really want to know where you people live and how you beat on your
machines, that Mutt's temporary file persistence is of such a huge
concern.  I've had to recover e-mail from Mutt's FCC or temporary
files exactly never, since I started using it in 1996.

> > > "/tmp-related bugs which are rendered non-exploitable by this mechanism
> > > are not treated as security vulnerabilities. If you use a custom
> > > Linux kernel you should enable it using a sysctl setting"
> > 
> > Ah.  I think the solution is not especially a good one, particularly
> > given that it is a system-wide behavior.  It makes using symlinks in
> > collaborative environments more difficult.
> 
> I don't think that symlinks in /tmp or similar that need to be shared
> occur in practice, even in collaborative environments. Or do you have
> an example?

I'm not talking about /tmp here.  Because it's system-wide, it also
applies to any case where you have directories intended to be written
by groups of users (so they probably have similar permissions to
/tmp).  It effectively disables symlinks in shared directories.  If
you're managing a Linux-based file server, this case very likely
applies to you, and you might feel the need to disable the feature.

If it were a mount option, as I previously suggested, you could easily
make it apply to ONLY /tmp (or whatever set of directories you need)
without applying it absolutely everywhere.  And because some folks
will disable the feature, system-wide, symlink attack bugs should
still be treated as fix required.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-dev/attachments/20190701/f8ee4cc3/attachment.asc>