bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

binutils (Re: more temp file problems)


From: Solar Designer
Subject: binutils (Re: more temp file problems)
Date: Wed, 10 Jan 2001 18:10:51 +0300
User-agent: Mutt/1.2.5i

> Marcus just checked binutils, here are his comments:
> 
> binutils:
>       Uses mktemp, but only in current directory.
> 
>       libiberty/make_tempfile() uses mkstemps(), which appears to be safe
> 
>       choose_temp_file() appears to be only called from Win32/Cygnus programs.

This mostly matches my initial impression (thanks for checking!), but
I did find a few problems since then.

choose_temp_file() is used by objdump and nlmconv(), which aren't
Win32-only:

david!good:~$ strace -fF -o z objdump -i /bin/ls > /dev/null
david!good:~$ grep /tmp z
17205 access("/tmp", R_OK|W_OK|X_OK)    = 0
17205 stat("/tmp/cc23dioR", 0xbffff8c4) = -1 ENOENT (No such file or directory)
17205 stat("/tmp/cc23dioR", 0xbffff910) = -1 ENOENT (No such file or directory)
17205 open("/tmp/cc23dioR", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
[...]
17205 unlink("/tmp/ccYHipzy")           = 0
17205 access("/tmp", R_OK|W_OK|X_OK)    = 0
17205 stat("/tmp/ccw7PHAf", 0xbffff894) = -1 ENOENT (No such file or directory)
17205 stat("/tmp/ccw7PHAf", 0xbffff8e0) = -1 ENOENT (No such file or directory)
17205 open("/tmp/ccw7PHAf", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5

(At least it supports $TMPDIR, which I've unset for this example.)

mktemp() is used not (or not only?) in the current directory, but in
the directory with the destination file, in at least ar.  Here's why
this may still be a problem in some cases:

david!good:~$ touch f
david!good:~$ F=`mktemp /tmp/tempfile.XXXXXX`
david!good:~$ echo $F
/tmp/tempfile.oZYJvo
david!good:~$ ar cr f.a f
david!good:~$ cat f.a > $F
david!good:~$ strace -fF -o z ar cr $F f
david!good:~$ grep /tmp z
17025 execve("/usr/bin/ar", ["ar", "cr", "/tmp/tempfile.oZYJvo", "f"], [/* 31 
vars */]) = 0
17025 stat("/tmp/tempfile.oZYJvo", {st_mode=S_IFREG|0600, st_size=68, ...}) = 0
17025 open("/tmp/tempfile.oZYJvo", O_RDONLY) = 5
17025 stat("/tmp/stjJVAqh", 0xbffff7a8) = -1 ENOENT (No such file or directory)
17025 stat("/tmp/stjJVAqh", 0xbffff808) = -1 ENOENT (No such file or directory)
17025 open("/tmp/stjJVAqh", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 7
17025 lstat("/tmp/tempfile.oZYJvo", {st_mode=S_IFREG|0600, st_size=68, ...}) = 0
17025 rename("/tmp/stjJVAqh", "/tmp/tempfile.oZYJvo") = 0
17025 chmod("/tmp/tempfile.oZYJvo", 0600) = 0
17025 chown("/tmp/tempfile.oZYJvo", 500, 500) = 0
17025 chmod("/tmp/tempfile.oZYJvo", 0600) = 0

In this case, the accesses to /tmp/tempfile.oZYJvo are safe as the
file already exists (and was initially created safely), while the
open() of /tmp/stjJVAqh is unsafe.

Is this use of ar uncommon?  I don't know, but given that ar is used
for many different purposes (including Debian packages), I suspect
there may be scripts which do things similar to the above example.

I think ar should be using mkstemps() as well.  And I would use mode
0600 in the open().

The same applies to objcopy (one use of make_tempname(), which is
mktemp()-based, is for a directory which may allow for at worst a DoS
against objcopy itself, but the other two uses are similar to that in
ar.)

-- 
/sd



reply via email to

[Prev in Thread] Current Thread [Next in Thread]