Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120502140004.GB17745@openwall.com>
Date: Wed, 2 May 2012 18:00:04 +0400
From: Solar Designer <solar@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: configure script for musl (?!)

Rich,

This approach (including not using autoconf specifically) makes sense to
me.  One general problem with it, though, is that errors are not
distinguished from actually and purposefully missing features.
Sometimes it is preferable for the build to fail when an expected system
feature is not present rather than for it to succeed with unexpectedly
altered functionality.  This is especially true if the non-detected
feature had security relevance.  On Owl, we have the configure-presets
script for this reason - to pre-populate autoconf configure's cache.

On Tue, May 01, 2012 at 07:39:26PM -0400, Rich Felker wrote:
> # Get a temp filename we can use
> test -n "$TMPDIR" && tmpc="$TMPDIR/conf$$.c" || tmpc="/tmp/conf$$.c"
> set -C
> > "$tmpc" || {
> echo "$0: cannot create temporary file $tmpc"
> exit 1
> }
> set +C
> trap 'rm "$tmpc"' EXIT

Is "set -C" sufficiently portable?  (I don't know.  I guess that it is
if you're using it here.)

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.

Another issue is that if the script is running with a relaxed umask like
002, then another user (in the same group, if relevant) may not only
notice that musl is being compiled, but also inject their own C code
into the temporary file and maybe take over the musl-building user
account (depending on whether you run the compiled code or not, as well
as on the compiler's features and bugs available to be invoked from the
source).  Perhaps you need to set a safe umask like 077 in this script
before it creates the temporary file (or chmod the file right after it's
been created, before its first actual use - and exit if the chmod fails).

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).

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.