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

[Michael Haubenwallner]

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

>> 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,
> 
> Ok.  We're talking about pre-installed binaries in the first place,
> right?

What do you call pre-installed binaries? It doesn't matter for the
binary when and by whom it was installed, either setup.exe - which
is non-cygwin, or some in-cygwin package manager - which relies on
the update-safe fork when replacing in-use binaries.

> I'm not yet clear on how this is going to handle binaries
> installed to another drive...

For now, when NtSetInformationFile (FileLinkInformation) does fail
for whatever reason (I cannot think of anything else than another
drive), this file is not hardlinked and will be used from its original
location. Must admit I haven't tested this scenario.

>> either as hardlink, copy, or symlink(?).

However, I can imagine two different cross-drive approaches:
* Either create some cygfork-directory on each drive to hold the
  hardlinks (still requires NTFS), and put symlinks into /var/run/
* or do a file-copy using the pre-opened handle into /var/run/
  (should work even with FAT, but would be slow).

>> Otherways we might have to
>> create some app.exe.manifest file - I've got lost in that docs...
> 
> Heh, yeah.  The manifest is pretty ugly, IMHO, especially the
> compatibility stuff since Windows 8.1.
> 
>>>> More 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.
> 
> We look into that when we get to it.

Ok then.

> Btw., I just skimmed your patch a bit and I stumbled over the usage of
> GetFileInformationByHandle.

Is there something wrong with GetFileInformationByHandle I should know of?
It can return FileId, LastWriteTime, and FileSize in one call...

> In dll_list::ctimename, please use NtQueryInformationFile with
> FileBasicInformation instead.  It allows to reduce the filetime
> comparison to a single test using the QuadPart of the timestamp and
> __small_swprintf simply uses a %016X.

Actually the FileInformation queried in dll_list::ctimename is reused
in dll_list::update_forkables_needs - have added a comment now.

> Analogue in dll_list::update_forkables_needs.  Do you really need to
> check the volume serial number?  Otherwise, just call
> NtQueryInformationFile(FileInternalInformation).

The idea behind checking the volume serial number is that I'm unsure
whether dlls can be replaced by symlinks to other drives as well, so
the FileId probably could become equal for different files...

BTW: MSDN document for FILE_INTERNAL_INFORMATION structure tells about
IndexNumber as the member - and so does /usr/include/w32api/, but
winsup/cygwin/ntdll.h does name it FileId - caused me some confusion...
Is that intentionally?

Thanks!
/haubi/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Protect-fork-against-dll-and-exe-updates.patch
Type: text/x-patch
Size: 54295 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20151116/f1936d79/attachment.bin>