This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi 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: bug in libffi with selinux and a fork


Jakub Jelinek wrote:
On Tue, Oct 27, 2009 at 12:58:44PM +0000, Andrew Haley wrote:
Victor Stinner wrote:
Le mardi 27 octobre 2009 13:42:45, Andrew Haley a écrit :
(...)
mmap2(NULL, 4096, PROT_READ|PROT_EXEC, MAP_SHARED, 3, 0) = 0xc41000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xb7c7d000
Hmmm, interesting. This is going to be quite hard to fix.
Whould it be possible to just replace MAP_SHARED by MAP_PRIVATE? If not, you may add a reference counter (which may require a mutex).

Why is the child process destroying the closure, anyway?
Why not? :-)
I might as well say "Don't do that, then." But I won't :-)

Would you like to try replacing MAP_SHARED with MAP_PRIVATE
and getting back to us?

MAP_PRIVATE wouldn't work at all, as the changes in the RW mapping wouldn't magically propagate into the RX mapping.

That's what I suspected.


Unfortunately pthread_atfork is -lpthread only thing (and when using threads
any use of libffi APIs in the child would be invalid anyway), so perhaps
closures.c should record the pid of the current process and if it notices a
different pid, it should reinitialize all its global variables to make sure
the file isn't shared nor the mappings.

But when would it notice? When destroying the closure, perhaps? You don't really want to do this on every invocation.

Andrew.


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