This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/13068] New: Use O_CLOEXEC for /etc/ld.so.cache and .so libraries
- From: "rosslagerwall at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Tue, 9 Aug 2011 06:12:42 +0000
- Subject: [Bug libc/13068] New: Use O_CLOEXEC for /etc/ld.so.cache and .so libraries
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=13068
Summary: Use O_CLOEXEC for /etc/ld.so.cache and .so libraries
Product: glibc
Version: 2.14
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper.fsp@gmail.com
ReportedBy: rosslagerwall@gmail.com
I have a problem with forking and threads.
One of the threads appears to call a dynamic library function which opens some
file descriptors without O_CLOEXEC. Another thread forks and so these fds are
then leaked to the child process after exec.
Relevant output from strace:
"""
# thread of parent opens fd without O_CLOEXEC
[pid 2766] open("/etc/ld.so.cache", O_RDONLY <unfinished ...>
# and another one
[pid 2766] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
"""
If a new child process is created, after theses calls, the fds will get
inherited after the exec.
It seems like this change was made in uclibc (for the cache file at least):
http://lists.busybox.net/pipermail/uclibc-cvs/2009-October/026908.html
I guess that the fix would be to simply open /etc/ld.so.cache and .so files
with O_CLOEXEC.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.