On Wed, Jun 16, 2010 at 3:57 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote: > On Wed, 2010-06-16 at 14:04 -0600, Eric Blake wrote: >> I'm with Stefan - the whole point of mkstemp is that the created file >> has 0600 permissions, and /tmp is restricted-deletion, so no other user >> can either overwrite the file contents or unlink it and replace it with >> an alternate file. Then again, gnulib documents that glibc 2.0.7 or >> older would create a file with group/other permissions if the umask >> wasn't set prior to the mkstemp() call, and gnulib's mkstemp() does not >> work around this issue; but that's a rather old version of glibc to be >> worrying about. > > This has nothing to do with mkstemp(). As I said, libvirt's use of it is > fine and there is no symlink race or security vulnerability by itself. > > The issue is that use of /tmp is not required *and* it becomes difficult > to properly confine libvirtd via a MAC if you must allow execution of > files in /tmp. See my answer to Stefan's question for an example > scenario. > > -- > Jamie Strandboge | http://www.canonical.com > For what it's worth, I've seen many times when people secure system that /tmp is mounted with noexec. If any of you have a shared web host and you can ssh into it and confirm. $ mount ...snip... /dev/mapper/vg-tmp on /tmp type ext3 (rw,noexec,nosuid,noatime) ...snip... -- Doug Goldstein -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list