[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120502150543.GB18084@openwall.com>
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.
