Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 2 May 2012 19:05:43 +0400
From: Solar Designer <>
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.


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.