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

[Derek Martin]

On Fri, Jun 28, 2019 at 11:08:06AM +0200, Vincent Lefevre wrote:
> On 2019-06-26 14:36:01 -0500, Derek Martin wrote:
> > On Wed, Jun 26, 2019 at 04:26:44PM +0200, Vincent Lefevre wrote:
> > > On 2019-06-25 14:26:16 -0500, Derek Martin wrote:
> > > > In some cases it might get cleaned up, but you can just have your
> > > > .profile (or whatever) recreate it when you log in... FWIW this is
> > > > probably what I would do in that case.
> > > 
> > > But if the directory has already been created by someone else,
> > > this is not OK. The solution must be compatible with Mutt's
> > > $tmpdir variable (which will not affect other applications,
> > > contrary to $TMPDIR).
> > 
> > Well, /tmp exists and was not created by you... ;-)
> 
> That's OK for /tmp, but not if I use, for instance
> 
> set tmpdir=/var/tmp/$USER

I think you missed my point.  How does Mutt KNOW /tmp is OK?  What if
it is not on your system?  I gave the example of Windows... it does
not use /tmp, though you can create it.  Other systems may use some
arbitrary thing, for arbitrary reasons.

Now what?

> 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.

> > 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.  No
competent admin will reboot the system on you without giving you 
some time to clean up what you're doing--you see the notification, and
postpone your message.  That does not live in $TMPDIR or $tmpdir.  By
default that's ~/postponed.  If you put it in $TMPDIR you have done
something dumb.

Nothing else mutt creates in $tmpdir makes much sense to require
persistence.  That basically leaves attachments and encoding
conversions, which are by nature ephemeral.  $TMPDIR is fine for
those, regardless of whether it is /tmp or /var/tmp.

> Different applications have different needs: some prefer performance,
> others need space (see the long discussion(s) after /tmp was switched
> to the faster tmpfs, but with little space).

I think this is mostly balderdash.  Small files will mostly take
negligible time to read from disk, and those that have been
accessed recently should generally be in buffer cache (i.e. RAM) so
tmpfs isn't any faster than that.  Larger files need space.  So
basically, don't use tmpfs, ever--it gets you both behaviors
automatically as appropriate, unless your system is under memory
pressure, in which case you have a different problem.

Exceptions with very specific usage patterns surely exist, but the
vast majority of users shouldn't notice or care, and those that do can
configure the system as appropriate FOR THOSE APPLICATIONS, setting
TMPDIR for them in a wrapper script.

The "long discussions" are, I would guesstimate, *mostly* people
complaining about problems they don't actually have.

> I think that Mutt should have an option to create a random directory
> under the specified temporary directory ($tmpdir or $TMPDIR or /tmp),
> and use that as the real temporary directory (some other applications
> or utilities do that). On exit, if this directory is empty, Mutt
> should remove it, and perhaps have a quad option if the directory
> is not empty (I believe that this should be unusual).

Obviously I don't. =8^)

> > > At least symlink attacks are now protected by the kernel (and BTW, a
> > > bug in some Debian package related to a symlink attack is no longer
> > > regarded as a security bug by Debian, no longer RC).
> > 
> > Eh?  You have a reference for this? I've not heard of it.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878138
> "muttprint: still vulnerable to symlink attack (race condition)"
> 
> I had reported the bug as grave, but got a response in
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878138#32
> 
> quoting:
> 
> "/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. In such cases the admin
might be inclined to disable it, which renders bugs which "are
rendered non-exploitable by this mechanism [and] are not treated as
security vulnerabilities" just as vulnerable as they ever were.

I could go into some detail about this, though I think we're getting
way out of the scope of this thread/list.  I might start a thread
about it on LKML though if I find myself with a few spare cycles.

FWIW many years ago I suggested something similar, but it was for hard
links, and it was a mount option.  Ted Tso seemed to like the idea,
but AFAIK it went nowhere.

-- 
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/20190628/bc9a3d5c/attachment.asc>