[PATCH] Define secure_getenv (v3)

[Florian Weimer]

On 07/20/2012 06:43 PM, Roland McGrath wrote:
>> Oh, will fix.  Is this about static linking?
>
> Today in practice in most cases it only makes a difference for static
> linking.  That's only because of our arcane PLT avoidance techniques.
> It's still not the case for references between shared libraries, like
> a libc function called by libm or librt, etc.
>
>> The existing sources do not follow this rule in all cases, so I assumed
>> it was expendable.
>
> The actual rule is more subtle than this.  So it may be that what
> you've observed are cases that are actually kosher.  If not, then
> those are bugs and we'd appreciate your reporting (or fixing!) any
> such cases you noticed.

Thanks for the explanation.

ptsname_r (_GNU_SOURCE) is used from openpty (not conditionally defined, 
but BSDish I think).  Would this qualify as treif?

Anyway, I'm attaching version 3 of the patch, which uses 
__libc_secure_getenv internally.  Testing passes on 
x86_64-redhat-linux-gnu.  I've verified that existing binaries linked 
against __secure_getenv still run with this version.

-- 
Florian Weimer / Red Hat Product Security Team


-------------- next part --------------
A non-text attachment was scrubbed...
Name: secure-getenv.patch
Type: text/x-patch
Size: 29791 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120723/57888fa9/attachment.bin>