qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Don Slutz <dslutz@verizon.com>,
	Patch Tracking <patches@linaro.org>
Subject: Re: [Qemu-devel] [PATCH] configure: Put tempfiles in subdir so we can clean up libtool files
Date: Tue, 06 May 2014 09:43:57 -0600	[thread overview]
Message-ID: <5369033D.5060505@redhat.com> (raw)
In-Reply-To: <CAFEAcA_muHezDUmdcvkEqp0pFmCBJ55kUXrSZkuUv05vxpJybw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

On 05/06/2014 08:53 AM, Peter Maydell wrote:

>> # Create a (secure) tmp directory for tmp files.
>>
>> {
>>   tmp=`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
>>   test -d "$tmp"
>> }  ||
>> {
>>   tmp=./conf$$-$RANDOM
>>   (umask 077 && mkdir "$tmp")
>> } || as_fn_error $? "cannot create a temporary directory in ." "$LINENO" 5
>> ac_tmp=$tmp
> 
> Yuck.
> 
>> The use of $$ and $RANDOM is safe (even on shells that lack $RANDOM)
>> because of the fact that mkdir is atomic and the umask is correctly set
>> prior to the mkdir.
> 
> I dislike the use of $RANDOM, because it means we behave
> inconsistently. If it's OK for $RANDOM to expand to "" then we
> should just not use it at all, because that's OK and the same
> everywhere.

It's okay for $RANDOM to expand to "" in the fallback code, for the
platforms that lack mktemp(1); most developers are on a platform that
have mktemp.  The use of $RANDOM makes it harder for an attacker to
pre-create a competing file by the same name, but does not add any
security; so omitting $RANDOM for the fallback path doesn't hurt if you
are that bothered by seeing it present in a dash script.

> 
> Similarly, if it's OK not to use mktemp on some systems,
> we should use the same non-mktemp code everywhere.

The fallback is not ideal, but tolerable.  It's still better to try and
use mktemp where it exists.

> 
> We could sidestep this rubbish by not trying to put our temp
> files in /tmp/, and instead just put them in the build directory
> (ie ./conf-temps/ or something similar, which we blow away
> and recreate every time).

Yes, using a different location for temporary files and avoiding /tmp
might also work.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

      reply	other threads:[~2014-05-06 15:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-06 13:17 [Qemu-devel] [PATCH] configure: Put tempfiles in subdir so we can clean up libtool files Peter Maydell
2014-05-06 14:36 ` Eric Blake
2014-05-06 14:53   ` Peter Maydell
2014-05-06 15:43     ` Eric Blake [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5369033D.5060505@redhat.com \
    --to=eblake@redhat.com \
    --cc=dslutz@verizon.com \
    --cc=patches@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).