Protect fork() against dll- and exe-updates.

Michael Haubenwallner
Mon Nov 16 09:01:00 GMT 2015

Hi Corinna,

On 11/14/2015 11:25 AM, Corinna Vinschen wrote:
> On Nov 13 17:12, Michael Haubenwallner wrote:

>> have reworked the hardlink-creation from scratch as discussed before,
>> now using /var/run/cygfork/ as the top-level hardlinks directory.
>> * At process start and during LoadLibrary, handles to all the loaded
>>   dlls (including cygwin1.dll) and the main executable are opened.

>> * If they are not identical (any more), hardlinks to these dlls are
>>   created in subdirectories into /var/run/cygfork/<sid>/.
> This description puzzles me a bit.  If the DLLs have changed, isn't
> it too late to create the hardlink?!?  I guess I'm missing something.

The hardlink is created using the handle opened during dll-initialization
(as we have discussed that before). Agreed there is the short time frame
between process start (where windows does open the dll) and opening the
file handle in dll-initialization, where the dll could be replaced - but
I'm not sure if that really will be that much of a problem.

>> * For the timing: Building cygwin-2.4.0-0.2 three times, the duration
>>   difference is in the range of measuring fault - almost identical for
>>   each possible variant vanilla,disabled,enabled,forced.
> Wow.  Really?
>> More thoughts?
> Yes, but I'm not sure yet.  I'm just wondering if /var/run or any
> other such dir is such a good idea after all.  I have this vague
> notion that a subdir of the directory the DLL is installed in might
> be safer in the log run (for DLLs in /bin a subdir of /bin, etc).

While I don't really care about /var/run, I doubt that /bin necessarily
is writeable for each user using a particular cygwin instance - or we
would have to create some cygfork directory with a=rwxt permission there
beforehand.  Also, for the dll-redirection to work, all the linktime
dll's need to be available nearby app.exe and the app.exe.local file,
either as hardlink, copy, or symlink(?). Otherways we might have to
create some app.exe.manifest file - I've got lost in that docs...

>> More to discuss?
> I'm a bit swamped ATM, but I'll try to take a look into your patch next
> week or the week after.  As for discussing, yes, I think so.  Please
> keep in mind that your patch is pretty intrusive, so there's certainly
> something to discuss :}

ATM, there's one thing I'm unsure whether it is necessary at all, and how
to do if yes: Purging the bin - where the hardlinks get moved to.

> I'm planning to fold in the cygwin-acl branch the week after and then
> release 2.4.0.  From there on we should create a feature branch from
> mainline and apply your changes to perform further testing and tweaking
> as necessary.
> Sounds ok?

Absolutely fine with me!

Thanks a lot!

More information about the Cygwin-developers mailing list