Date: Wed, 2 May 2012 19:05:43 +0400 From: Solar Designer <solar@...nwall.com> To: musl@...ts.openwall.com Subject: Re: configure script for musl (?!) On Wed, May 02, 2012 at 10:31:25AM -0400, Rich Felker wrote: > On Wed, May 02, 2012 at 06:00:04PM +0400, Solar Designer wrote: > > Is "set -C" sufficiently portable? (I don't know. I guess that it is > > if you're using it here.) > > It's POSIX. My policy for this and future configure scripts I write is > that you need a POSIX compatible shell to run configure. This is the > same as MPlayer and FFmpeg/libav policy and I remember they took some > heat for it back in the day from users of broken unices like Solaris, > but telling those users to add /usr/xpg4/bin to their path and invoke > configure with that version of the shell generally made them happy. I > suspect it's a non-issue in 2012, and especially for musl where > building on anything non-Linux-based (and thus anything without > [bd]?ash as the shell) is going to be a special cross-compiling case. I think the biggest problem here is in the failure mode. In the draft script you posted, if "set -C" fails the script will proceed to potentially clobber a file via a (sym)link provided by another user, or it may use a FIFO or a regular file pre-created by another user (and set to e.g. mode 666), in which case the input to the compiler would be under that other user's control (even if we're running with a safe umask). > > Assuming that "set -C" works, another user is able to prevent the above > > from working by pre-creating the file. I understand that you can't just > > use mktemp here, and implementing its full functionality right in your > > shell script is not pretty. > > Yes, mktemp does not work because it does not let you specify a > suffix, and most compilers fail to recognize input files as C unless > they have a .c suffix. It has a dry run option just to generate the > filename (and let the caller handle creating it like we do now) but > unfortunately busybox mktemp does not know that option so it doesn't > seem at all safe/portable. > > I've actually been working on the issue and updated it to use $$, > $PPID, and a retry counter, so random failures will be extremely rare. > If anyone thinks it still matters, I'll add $(date|cksum) too. Oh, I think it's better to simply use the approach I suggested last: > > Rather than use $TMPDIR or /tmp, I think it'd be safer to place the file > > in the same directory with the configure script or in the current > > directory. You're going to create config.mak in one of these > > directories anyway - so just create the temporary file in that same > > directory not to incur any extra risk (that you do by writing into a > > second directory). > > This seems reasonable. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.