openstack team mailing list archive

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Mon, Jul 02, 2012 at 12:09:55PM -0700, Johannes Erdfelt wrote:
> On Mon, Jul 02, 2012, Daniel P. Berrange <berrange@xxxxxxxxxx> 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.

We already run a bunch of PEP8 checks across the code on every
commit. It ought to be with the realm of practicality to add a
rule that blacklists any use of mkdtemp() which does not pass
an explicit directory. Most places in Nova don't actually use
it directly, but instead call nova.utils.tempdir() which could
again be made to default to '/var/lib/nova/tmp' or equivalent.


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

These are all reasons against use of /tmp - precisely because it is
so convenient/easy, developers use it without ever thinking about the
possible consequences of accidental misuse.

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

It is fairly common for apps to use /var/cache/<appname> or
/var/lib/<appname>.

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

That is possible, but I simply disagree with your point that we
can't stop using /tmp. It is entirely possible to stop using it
IMHO.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|