This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Document __secure_getenv


On 07/11/2012 05:25 PM, Carlos O'Donell wrote:

__secure_getenv has been available basically since forever.  I hope
it's not going away.  In application code, an alternative name would
need a configure check or libc version check, plus an out-of-line
copy or fallback to __secure_getenv.  Perhaps this is avoidable.

The __ namespace is reserved for the implementation, unless you are part of the implementation you should not rely on anything there.

Surely it's acceptable to use a __ symbol if the implementer says so. You make the rules for those symbols.


If the community wants to export __secure_getenv, then as Roland says,
we should export it with a public name and document the behaviour.

It is already exported. gnulib and gettext use it. I doubt you can remove it without breaking backwards compatibility.


Your next steps:
- Work up a patch that gives __secure_getenv a public interface.
- Fixup the documentation to use the new interface name.

I cannot use the new symbol because that would introduce a dependency on a new libc version. From my perspective, the alternatives are:


1) Use __secure_getenv.

2) Try to reimplement __secure_getenv with UID/GID comparisons and prctl and copy that code into all libraries and applications which need it.

But 2) is problematic if the check ever needs to change, so I want to avoid that.

--
Florian Weimer / Red Hat Product Security Team


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]