Date: Tue, 20 Oct 1998 15:31:00 -0600 From: Warner Losh <imp@village.org> To: Bruce Evans <bde@zeta.org.au> Cc: peter@netplex.com.au, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdio mktemp.c Message-ID: <199810202131.PAA28874@harmony.village.org> In-Reply-To: Your message of "Wed, 21 Oct 1998 02:28:35 %2B1000." <199810201628.CAA15294@godzilla.zeta.org.au> References: <199810201628.CAA15294@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199810201628.CAA15294@godzilla.zeta.org.au> Bruce Evans writes: : > fd = mkstemp(foo); : > unlink(foo); : : This has a race between the mkstemp() and the unlink(). ???? What's the race here? : Who owns it? The Linux (Redhat version mumble) man page says that : mkstemp() conforms to BSD 4.3 and creates the file with permissions : 0666. glibc-2.0.5c uses the same O_EXCL open as us except for using : this insecure mode. Linux has it wrong. mkstemp should create a file that no one else can read or, especially, write. If it doesn't, then all kinds of problems exist in the tree. I don't care what tradition says on this point: it introduces an unacceptable security problem. O_EXCL doesn't work through the file system, except when you are creating a file, so the insecure mode is very insecure indeed. By doesn't work, I mean that it doesn't give you an exclusive lock on the file like it does for a device whose driver has been writtne to grok O_EXCL. Consider someone building a system whose compiler uses mkstemp which allows others to read/write the tmp file. A hacker could win the race once and insert arbitrary code unbeknowst to the builder of the system.... There are also disclusre issues for mail readers and the like. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810202131.PAA28874>