When I integrated NTP v4 into Nevada, I included a test in the startup method to check if the service was running in the global zone and to fail if it were not. This seemed reasonable because the privs necessary for NTP to control the system clock are only available in the global zone.
However, I forgot to take into account the fact that extra privs can now be added to the local zones, which would allow ntpd to run in a local zones. Furthermore, customers have expressed a desire to run ntpd in local zones for various reasons. My first thought was simply to change the test for the zone into a test for the privs, but Darren Moffet talked me out of this approach, since the right way to do priv testing is to either test for a priv when you need it or even let the operation fail. Furthermore, there actually some modes of operation of ntpd that don't really need the privs at all, specifically to monitor other systems. So, I thought to just remove the tests altogether. There is still a problem, though. The one absolute of NTP is that while NTP is running, nothing else should ever, ever, adjust the clock. Of particular danger in this regard would be another ntpd process. If I remove the test and allow ntpd to run in other zones, we all know that there will be systems that end up with NTP running in multiple zones simultaneously. What makes this very bad is that ntpd cannot detect this situation. It will just start making adjustments to the system clock and so will the other ntpd's causing much confusion to the kernel, which will assuredly end up with the clock speed fluctuating madly. While it would be possible for the global zone startup method to detect if there is any other ntpd processes actually running the local zones, the converse is not true. I don't think there is any reasonable way for a service in a local zone to check if the same service is enabled in any other zones, including the global zone. The best idea I could come up with is to have a service property to disable the check for global zone and for the priv, one for each, and in the man pages where those properties are described, include all kinds of dire warnings about it. That way at least it would take an active administrative action to allow this to work. The global zone admin would have to configure the clock adjustment privs and the local zone administrator would have to turn off the tests. I think that is the best we can reasonably do. If anybody has any better ideas, or comments on the "right way" to do this, please let me know. -- blu It's bad civic hygiene to build technologies that could someday be used to facilitate a police state. - Bruce Schneier ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Oracle Corporation. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
