[ntp:hackers] Re-adding support of Windows shared memory to NTP

Jolidon, Jérôme Jerome.Jolidon at swisstiming.com
Thu Apr 25 12:22:54 UTC 2019

Note: the mail below has already been sent to the list before, but for some unknown reason it was not forwarded. I'm resending it to see if it was a fluke or something else.

Hello all,

I have spent a bit of time to add support of shared memory in the Windows builds of ntp. The code resides in a fork on github, at the address https://github.com/jjolidon/ntp. The git patches are also attached.
I would very much appreciate your thoughts and comments.
If the code fully suits the quality requirements and coding conventions of ntp, feel free to include it in the baseline. Otherwise, I am prepared to spend some time for corrections if interest is shown.

The code was already mostly existing but I had to make a few changes to make it safer and fully functional:
-	The code did not set any ACL when the forall flag was set. This could lead to issues with other users grabbing all permissions on the segment, even though it is mitigated by the fact that the segment always required admin privileges for opening (see below). I have changed that, the ACL are now always set.
-	Windows services always open shared memory in the Global namespace, even when the segment name is prefixed with Local, so the distinction between forall and not forall is less evident for the services. I have translated that to ACL mappings: ownership of the segment is always set to the current user, and r/w permission are added for all logged users when the forall flag is set.
-	In addition to these ACL changes, I have implemented a whitelisting principle for the ACL: the code reads a registry key and adds any SID found in the key with r/w permissions. This is done whether the forall flag is set or not. Potentially the permissions set through the registry could be redundant with the forall flag, but this does not seem problematic.

In addition to these changes, I have made changes to the build configurations in order to be able to build with Visual Studio 2017 on recent Windows 10 SDKs:
-	I have created a Visual Studio 2017 solution, as was done for the previous versions of the tool.
-	Recent SDKs include a definition of timespec. I have created a conditional compilation symbol that hides the in-house structure when set. It is specifically enabled in the Visual Studio 2017 solution. This should not be problematic to other platforms and toolchains, I believe.
-	During builds Visual Studio mentioned a code quality issue relative to the order of definitions of STATUS_SEVERITY_WARNING (0x2) not respecting the byte order, as it was defined before STATUS_SEVERITY_SUCCESS (0x0) and STATUS_SEVERITY_INFORMATIONAL (0x1). This is a very minor fix but I included it nonetheless.
-	The compilation of the shared memory support is enabled in the Visual Studio 2017 solution.

Thanks in advance for your attention and your reactions.


Jérôme Jolidon
Senior Software Developer
Swiss Timing LTD
Rue de l'Envers 1
CH-2606 Corgémont - Switzerland

Phone  +41 32 4883611
Jerome.Jolidon at swisstiming.com

This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. If you are not the intended
recipient please do not read, save, forward, disclose or copy the contents
of this e-mail. If this e-mail has been sent to you in error, please delete this 
e-mail and any copies or links to this e-mail completely and immediately
from your system. We also like to inform you that communication via e-mail
over the Internet is insecure because third parties may have the possibility
to access and manipulate e-mails.

Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
The Swatch Group Ltd.

More information about the hackers mailing list