Open Stack

On Mon, Jul 02, 2012, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Mon, Jul 02, 2012 at 08:17:08AM -0700, Johannes Erdfelt wrote:
> > Not using /tmp for large files is a good reason for practical reasons
> > (distributions moving to ramfs for /tmp).
> > 
> > But please don't start throwing around warnings that all uses of /tmp
> > are a security risk without backing that up.
> 
> I stand by my point that in general usage of /tmp is a risk because
> for every experianced developer who can get things right, there are
> hordes of others who get it wrong & eventually one such bug will
> slip through the review net. Since there are rarely compelling reasons
> for the use of /tmp, avoiding it by default is a good defensive choice.

So your argument isn't that using /tmp is inherently insecure, it's that
using something not shared is safer?

It seems to me that we're just as likely to have a review slip through
that uses /tmp insecurely as a review slipping through that uses /tmp at
all.

Ultimately, the most compelling reason for using /tmp is that it's easy,
it's standard and developers have been trained to use it for a long
time.

There is no well-defined alternative, either in LSB or in practice (or
in either that blog post or your email).

Since we can't trust developers to use /tmp securely, or avoid using
/tmp at all, then why not use filesystem namespaces to setup a process
specific non-shared /tmp?

Nova never shares anything in /tmp (or at least shouldn't), so it should
be safe.

JE