[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140718015858.GW17402@brightrain.aerifal.cx>
Date: Thu, 17 Jul 2014 21:58:58 -0400
From: Rich Felker <dalias@...c.org>
To: Isaac Dunham <ibid.ag@...il.com>
Cc: Brent Cook <busterb@...il.com>, musl@...ts.openwall.com,
beck@...nbsd.org
Subject: Re: [PATCH] implement issetugid(2) (v4)
On Sat, Jul 19, 2014 at 04:11:17AM -0700, Isaac Dunham wrote:
> A thought recently crossed my mind regarding getauxval(AT_SECURE):
> what does this do under Linux emulation on other platforms?
> Most of the BSDs have Linux emulation, as well as Solaris;
> there was also LINA for Windows and OS X.
> But I haven't found statements about what happens to getauxval().
Both glibc's and musl's getauxval will just return results from
whatever aux vector the kernel gave the program when it started. If
AT_SECURE is missing from the aux vector the kernel provides, this
will lead to ENOENT on musl and newer glibc, and to a false negative
on old glibc.
For this reason I think musl should intercept the request for
AT_SECURE and simply return libc.secure rather than the value in the
aux vector. In principle applications should be checking for ENOENT,
but since glibc "guarantees" it cannot happen by not supporting
pre-AT_SECURE kernels (and not making any statement about other
kernels with Linux emulation), applications are likely to be skipping
the ENOENT check.
Rich
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.
