On Mon, Jul 02, 2012, Daniel P. Berrange <berra...@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
