From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2699 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Add support for mkostemp, mkstemps and mkostemps Date: Wed, 30 Jan 2013 02:21:08 -0500 Message-ID: <20130130072108.GN20323@brightrain.aerifal.cx> References: <1359349583-3643-1-git-send-email-basile@opensource.dyc.edu> <20130128093755.GI10600@port70.net> <5108583B.4080002@opensource.dyc.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1359530483 25725 80.91.229.3 (30 Jan 2013 07:21:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jan 2013 07:21:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2700-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 30 08:21:44 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1U0RzI-0007rZ-01 for gllmg-musl@plane.gmane.org; Wed, 30 Jan 2013 08:21:40 +0100 Original-Received: (qmail 9495 invoked by uid 550); 30 Jan 2013 07:21:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9486 invoked from network); 30 Jan 2013 07:21:20 -0000 Content-Disposition: inline In-Reply-To: <5108583B.4080002@opensource.dyc.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2699 Archived-At: On Tue, Jan 29, 2013 at 06:16:11PM -0500, Anthony G. Basile wrote: > Hi Szabolcs, > > Thanks for the feedback. All these improvements are easy to > implement, but the random name generator definitely needs a better > algorithm. I just adopted what was already there, but its not good > enough. > > Here's a simple test program which demonstrates the problem: > > #include > #include > #include > #include > > int main() > { > int i, fd; > char *t = (char *)malloc(7); > > for(i = 0; i < 10; i++) > { > strcpy(t, "XXXXXX"); > fd = mkstemp(t); > printf("%s\n", t); > close(fd); > unlink(t); > } > > return 0; > } > > > On a glibc system, we get something like: > > 4FeUYd > gZd1x7 > wkq860 > y2QfGU > e9rnfO > crdvOH > 0P9CnB > m0cLWu > eVuTvo > cxT14h > > On uclibc we get > > WJMzFT > nvSCqr > fneEMi > DTWxB1 > SH4n1C > TwLMQ9 > LVyEHe > EihiL4 > uaqxr4 > xmqe7O > > > On musl we get > > GIJNPM > GJDGKC > GJJBDH > GJOFHL > GKFHON > GKLIPB > GLCDJK > GLHONA > GMABAH > GMGPLG Is your concern denial of service by creating all possible temp names for a given prefix? With 6 characters and 4 bits per character, there are 2^24 possibilities. That's definitely high enough to avoid problems from unintended collisions, but I think it's in the realm of "possible" for an attacker to create them all (it would fill up quite an enormous amount of directory table space, however, probably over a gig, and stress the filesystem pretty bad). One trivial way to get an extra bit per letter would be to add the lower 4 bits to 'A' and then or the 5th bit onto the result (which would lowercase it). This would up the number of possibilities to 2^30, which is getting pretty high. Of course it would be nicer to get up to 6 bits per character (base64), or even more like 6.5, using modulo rather than &. However, using non-alphanumeric characters has some tradeoffs; one has to ask whether the added security against temp name exhaustion DoS is worth the risk of broken programs passing filenames generated by mkstemp on system(), popen(), etc. unquoted, which would be dangerous if they happened to contain characters special to the shell. > Let me play around with some different algorithms and resubmit this. > I'll look at what uclibc and glibc do and try to slim them down and > speed them up. I don't think performance is an issue unless you're talking about extra syscalls. The bulk of the time spent in this function is syscalls, so even making the userspace part of the code 100x faster is not going to be noticable. I would aim just for small size and simplicity. Rich