On 01/29/2013 10:47 AM, Jakub Jelinek wrote:
Precisely because it's in the private namespace, glibc could just
have documented the existing __secure_getenv symbol. It's not that
there aren't any public functions starting with __. But this was
rejected by upstream, and now we have the __secure_getenv
compatibility symbol (not usable for fresh linking), secure_getenv,
and __libc_secure_getenv for internal glibc use (but which is still
public for technical reasons).
A @@GLIBC_PRIVATE symbol is not public.
nss_hesiod needs secure_getenv, so a non-private symbol is needed. In
any case, I can link against __libc_secure_getenv in Fedora rawhide:
<mock-chroot>[root@oldenburg tmp]# rpm -q glibc
glibc-2.17-1.fc19.x86_64
<mock-chroot>[root@oldenburg tmp]# cat t.c
void __libc_secure_getenv();
int main()
{
__libc_secure_getenv();
return 0;
}
<mock-chroot>[root@oldenburg tmp]# gcc t.c
<mock-chroot>[root@oldenburg tmp]#
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
