[PATCH] winsup/cygwin: Protect fork() against dll- and exe-updates.

[Michael Haubenwallner]

Hi!

When starting to port Gentoo Prefix to Cygwin, the first real problem
discovered is that fork() does use the original executable's location
to Create the child's Process, probably finding linked dlls that just
have emerged in the current directory (sth. like /my/prefix/usr/bin),
causing "Loaded different DLL with same basename in forked child" errors.

Diving into the details, I'm coming up with (a patch-draft based on) the
idea to create hardlinks for the binaries-in-use into some cygwin-specific
directory, like \proc\<ntpid>\object\ ('ve seen this name on AIX),
and use these hardlinks instead to create the new child's process.

Thoughts so far?

For now, when <cygroot>\proc\ directory does exist, the patch (roughly) does:

For /bin/bash.exe, cygwin1.dll creates these hardlinks at process startup:
  \proc\<ntpid>\object\bash.exe         -> /bin/bash.exe
  \proc\<ntpid>\object\bash.exe.local      (empty file for dll redirection)
  \proc\<ntpid>\object\cygwin1.dll      -> /bin/cygwin1.dll
  \proc\<ntpid>\object\cygreadline7.dll -> /bin/cygreadline7.dll

And frok::parent then does:

  CreateProcess("\proc\<ntpid>\object\bash.exe", "/bin/bash.exe", ...)

Resulting in another \proc\<ntpid>\object\ directory with same hardlinks.

While attached patch does work so far already, there's a few issues:

*) dll-redirection for LoadLibrary using "app.exe.local" file does operate on
   the dll's basename only, breaking perl's Hash::Util and List::Util at least.
   So creating hardlinks for dynamically loaded dlls is disabled for now.
   Eventually, manifests and/or app.exe.config could help here, but I'm still
   failing to really grok them...

*) Who can clean up \proc\<ntpid>\ directory after power-loss or similar?
   For now, if stale \proc\<ntpid>\ is found, it is removed beforehand.
   But when this was from a different user, cleanup will fail. However,
   using \proc\S-<current-user-id>\<ntpid>\ instead could help here...

*) Is it really necessary to create these hardlinks in the real filesystem?
   I could imagine to create them directly in $Recycle.bin instead, or some
   (other) memory-only thing...

Thoughts welcome!

Thank you!
/haubi/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Protect-fork-against-dll-and-exe-updates.patch
Type: text/x-patch
Size: 29788 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20150724/f7b013e1/attachment.bin>