[ntp:hackers] Re: Config file format

Brian Utterback Brian.Utterback at Sun.COM
Mon Feb 21 13:53:49 PST 2005


David L. Mills wrote:

> Brian & Co.,
>
> Can we do this in stages? I really and truly do want the configuration 
> mess to be cleaned up so valuable features like Manycast server 
> discovery can be implemented. I see real problems with the 
> configuration interface to the various modules in the system, 
> asynchronous DNS and so forth. Security is really simple. No remote 
> configuration for now. No HTTP for now. Can we get this ship moving?
>
> Dave
>
> Brian Utterback wrote:
>
>> Mark Martinec wrote:
>>
>>>> Please show me how *allowing* a URL to specify how the conf file gets
>>>> loaded is a hole.
>>>>
>>>> All I'm saying is that I have seen many places where this 
>>>> capability would
>>>> be a major win.  I'm not telling people to use it, and I'm not 
>>>> going to
>>>> force anybody to use it.
>>>>   
>>>
>>>
>>>
>>> on a plus side: it can add flexibility for some installations;
>>>
>>> on a minus side: it adds complexity. Some may remember that a
>>>  popular command-line http/ftp client 'wget' is being plagued
>>>  with security holes, being discovered one after another.
>>>  Add SSL, and it all gets even worse.
>>>
>>> If one is prepared to sacrifice a potential ability to HUP a daemon
>>> and make it reload a config file, then perhaps a simple:
>>>
>>>  ntpd -c -
>>>
>>> (to read config from stdin) could offer as much flexibility
>>> as one is prepared to put into his startup script.
>>>
>>> P.S. most of us recipients are on the hackers list,
>>>     please avoid sending duplicates
>>>
>>> Mark
>>>
>>
>> Security is just the implementation of a policy. No two people will 
>> agree on what the security requirements
>> are. Ideally, we want to provide an administrative system that has a 
>> near to zero admin cost while providing
>> as much  security than anybody would reasonably want. If we cannot do 
>> that, then we need to provide a
>> system flexible enough to accommodate whatever level of security is 
>> required by the particular needs of the
>> policy makers at a site. For some, zero admin far outclasses the 
>> security requirement. For others, bad security
>> is a show stopper. NFS mounting the config files is probably not 
>> enough security for many. Although NFS
>> can be configured to use the same level of security as the NTP 
>> authentication does, how many of us have
>> really done this in practice? Dave, does your /usr/loca/etc/ mount 
>> really have crypto auth configured? If
>> so, then I applaud you. Will the next guy, though?
>>
>> I think that the proposal is a good compromise. I don't think all 
>> protocols are appropriate for all places
>> though. What I suggest is the creation of a modular API for the 
>> configuration file, and a switch to call the
>> configured modules. So, by default, only "-", "/absolute/path" and 
>> "file:///absolute/path" are compiled in, with
>> easily used hooks to add whatever protocols people want, such as 
>> "http:", "https:", "ldap:", etc. Then people can
>> easily add new ones as required (for instance, Sun will be converting 
>> all daemons to use the new SMF facility
>> for configuration.) and once donated to the project, they can be 
>> enabled or not via --with options.
>>
>> Brian Utterback
>> brian.utterback at sun.com
>
I absolutely approve of doing it in stages. What I am suggesting is 
putting in the hooks for additional
protocols in the future, and allow only the three forms of file to start 
with. Those being "-" for stdin,
"/path" and "file:///path". Nothing more than that is needed at this stage.

Brian Utterback
brian.utterback at sun.com



More information about the hackers mailing list