Bug#562065: ntp server didn't support mssntp
Subject: ntp server didn't support mssntp Package: ntp Version: 4.2.4p4+dfsg-8lenny3 Severity: wishlist Tags: patch Current version of ntp in debian do not support MS SNTP extension. This extension is needed by Windows workstation in order to trust ntp source from AD server. Lately the Samba project made great improvement in the next version of Samba: Samba4 which is supposed to be a real replacement to Microsoft Active Directory. In order to act completely as an Domain Controller the Samba4 server must be able to act as a ntp server with the MS SNTP extension. Version 4.2.6 of ntp (released on 12/12/09) now include patches for allowing this extension but must be complied specifically with the option --enable-ntp-signd to effectively build this extension. Building this extension do not mean that it wil be active by default, in fact it has to be opted in by adding the following directive to ntp.conf: restrict foobar mssntp Where foobar is either default or a network address. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: [pkg-ntp-maintainers] Bug#562065: ntp server didn't support mssntp
On Tue, Dec 22, 2009 at 02:33:54PM +0300, Matthieu Patou wrote: Subject: ntp server didn't support mssntp Package: ntp Version: 4.2.4p4+dfsg-8lenny3 Severity: wishlist Tags: patch You tagged it patch, but you don't provide any patch? Current version of ntp in debian do not support MS SNTP extension. [...] Version 4.2.6 of ntp (released on 12/12/09) now include patches for allowing this extension but must be complied specifically with the option --enable-ntp-signd to effectively build this extension. So this is a wishlist bug asking for a new upstream version with tht configure option? Any idea why this isn't on by default? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: [pkg-ntp-maintainers] Bug#562065: ntp server didn't support mssntp
On 22/12/2009 20:53, Kurt Roeckx wrote:
On Tue, Dec 22, 2009 at 02:33:54PM +0300, Matthieu Patou wrote:
Subject: ntp server didn't support mssntp
Package: ntp
Version: 4.2.4p4+dfsg-8lenny3
Severity: wishlist
Tags: patch
You tagged it patch, but you don't provide any patch?
No good excuse, but I was missing a category saying that the patch is
already in the upstream source.
Current version of ntp in debian do not support MS SNTP extension.
[...]
Version 4.2.6 of ntp (released on 12/12/09) now include patches for
allowing this extension but must be complied specifically with the
option --enable-ntp-signd to effectively build this extension.
So this is a wishlist bug asking for a new upstream version
with tht configure option? Any idea why this isn't on by default?
See the talk in this bug
https://support.ntp.org/bugs/show_bug.cgi?id=1405. Basically I'll say
that Ph. D. Mills is a bit overcautious as he don't want ntp to be
blamed for an admin that activated this option and get flooded. It's in
fact the same problem as refclock that has to be explicitly activated
during configure if you want to have it (as debian does).
I am not of course willing to make debian user run a risk when using the
new version of ntp with this extension. So it must be noted that even if
the extension is built in the ntp server it must be opted in to start to
work. This piece of code protects the emission to the signed socket:
if (flags RES_MSSNTP) {
send_via_ntp_signd(rbufp, xmode, xkeyid, flags, xpkt);
return;
}
If no restrict is defined or if didn't match the user ip address then
the send_via_ntp_signd is not called.
It's obvious that any publicly available server shoudn't have this
activated.
In any case if this option is activated and no samba4 server is there to
answer (because the admin has misconfigurated his/her server). There
will be no such hang. The local kernel knows if the socket does not
exist, or no process is bound to it (because the author of the patch
choose to use unix domain socket).
(from an strace of ux_client, the code I based the ntp code on):
connect(3, {sa_family=AF_FILE, path=/tmp/ux_demo}, 110) = -1
ECONNREFUSED (Connection refused)
So it will cost 1 syscall.
Of course if the option is activated and a samba4 server is running then
there is a risk of DOS _but_ it means that the admin is making his
active directory directly available on internet so I guess that there
worse problems in this case.
Matthieu.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: [pkg-ntp-maintainers] Bug#562065: ntp server didn't support mssntp
On Tue, Dec 22, 2009 at 09:53:00PM +0300, Matthieu Patou wrote:
On 22/12/2009 20:53, Kurt Roeckx wrote:
On Tue, Dec 22, 2009 at 02:33:54PM +0300, Matthieu Patou wrote:
Subject: ntp server didn't support mssntp
Package: ntp
Version: 4.2.4p4+dfsg-8lenny3
Severity: wishlist
Tags: patch
You tagged it patch, but you don't provide any patch?
No good excuse, but I was missing a category saying that the patch
is already in the upstream source.
Current version of ntp in debian do not support MS SNTP extension.
[...]
Version 4.2.6 of ntp (released on 12/12/09) now include patches for
allowing this extension but must be complied specifically with the
option --enable-ntp-signd to effectively build this extension.
So this is a wishlist bug asking for a new upstream version
with tht configure option? Any idea why this isn't on by default?
See the talk in this bug
https://support.ntp.org/bugs/show_bug.cgi?id=1405. Basically I'll
say that Ph. D. Mills is a bit overcautious as he don't want ntp to
be blamed for an admin that activated this option and get flooded.
It's in fact the same problem as refclock that has to be explicitly
activated during configure if you want to have it (as debian does).
I am not of course willing to make debian user run a risk when using
the new version of ntp with this extension. So it must be noted that
even if the extension is built in the ntp server it must be opted in
to start to work. This piece of code protects the emission to the
signed socket:
if (flags RES_MSSNTP) {
send_via_ntp_signd(rbufp, xmode, xkeyid, flags, xpkt);
return;
}
If no restrict is defined or if didn't match the user ip address
then the send_via_ntp_signd is not called.
It's obvious that any publicly available server shoudn't have this
activated.
As I understand David L. Mills, it always opens a TCP socket
independent of the configuration file, and that that can be
used to DoS the server. If that's not the case I see no
problem with enabling this by default.
Kurt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: [pkg-ntp-maintainers] Bug#562065: ntp server didn't support mssntp
On 22/12/2009 22:25, Kurt Roeckx wrote:
On Tue, Dec 22, 2009 at 09:53:00PM +0300, Matthieu Patou wrote:
On 22/12/2009 20:53, Kurt Roeckx wrote:
On Tue, Dec 22, 2009 at 02:33:54PM +0300, Matthieu Patou wrote:
Subject: ntp server didn't support mssntp
Package: ntp
Version: 4.2.4p4+dfsg-8lenny3
Severity: wishlist
Tags: patch
You tagged it patch, but you don't provide any patch?
No good excuse, but I was missing a category saying that the patch
is already in the upstream source.
Current version of ntp in debian do not support MS SNTP extension.
[...]
Version 4.2.6 of ntp (released on 12/12/09) now include patches for
allowing this extension but must be complied specifically with the
option --enable-ntp-signd to effectively build this extension.
So this is a wishlist bug asking for a new upstream version
with tht configure option? Any idea why this isn't on by default?
See the talk in this bug
https://support.ntp.org/bugs/show_bug.cgi?id=1405. Basically I'll
say that Ph. D. Mills is a bit overcautious as he don't want ntp to
be blamed for an admin that activated this option and get flooded.
It's in fact the same problem as refclock that has to be explicitly
activated during configure if you want to have it (as debian does).
I am not of course willing to make debian user run a risk when using
the new version of ntp with this extension. So it must be noted that
even if the extension is built in the ntp server it must be opted in
to start to work. This piece of code protects the emission to the
signed socket:
if (flags RES_MSSNTP) {
send_via_ntp_signd(rbufp, xmode, xkeyid, flags,xpkt);
return;
}
If no restrict is defined or if didn't match the user ip address
then the send_via_ntp_signd is not called.
It's obvious that any publicly available server shoudn't have this
activated.
As I understand David L. Mills, it always opens a TCP socket
independent of the configuration file, and that that can be
used to DoS the server. If that's not the case I see no
problem with enabling this by default.
I'm sorry to put it through David L. Mills was wrong on this.
The patch never used a TCP socket but a unix socket. And since the
initial patch the code has been reworked to be wrapped in a test that
avoid trying to open the unix socket unless the requester has been
allowed to do so in the configuration.
It's this piece of code that check and if allowed open the signd socket.
if (flags RES_MSSNTP) {
send_via_ntp_signd(rbufp, xmode, xkeyid, flags,xpkt);
return;
}
Matthieu.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: [pkg-ntp-maintainers] Bug#562065: ntp server didn't support mssntp
On Tue, Dec 22, 2009 at 11:29:24PM +0300, Matthieu Patou wrote: I'm sorry to put it through David L. Mills was wrong on this. The patch never used a TCP socket but a unix socket. And since the initial patch the code has been reworked to be wrapped in a test that avoid trying to open the unix socket unless the requester has been allowed to do so in the configuration. I guess I'm missing something here. I'm just going to make a guess of how this works (if enabled): 1) We wait to get a UDP message 2) We send something to samba over the unix domain socket He thought this was over TCP, and that's beside the point, we need to wait until there is room in the kernel buffer. 3) We wait for a reply from samba, we do not process any other packages while waiting. 4) We send a message back 5) go to 1) And the restrict lines controls if we're going to send something to samba or not. An other alternative could be that we don't wait for packet back but that samba actually sends back the reply, doesn't make much difference. Anyway, in either case I don't see a problem with giving the admin the option of enabling it in the config file. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562065: [pkg-ntp-maintainers] Bug#562065: ntp server didn't support mssntp
On 23/12/2009 00:00, Kurt Roeckx wrote: On Tue, Dec 22, 2009 at 11:29:24PM +0300, Matthieu Patou wrote: I'm sorry to put it through David L. Mills was wrong on this. The patch never used a TCP socket but a unix socket. And since the initial patch the code has been reworked to be wrapped in a test that avoid trying to open the unix socket unless the requester has been allowed to do so in the configuration. I guess I'm missing something here. I'm just going to make a guess of how this works (if enabled): 1) We wait to get a UDP message 2) We send something to samba over the unix domain socket He thought this was over TCP, and that's beside the point, we need to wait until there is room in the kernel buffer. This is only if there is a request for a signed packet. 3) We wait for a reply from samba, we do not process any other packages while waiting. 4) We send a message back 5) go to 1) And the restrict lines controls if we're going to send something to samba or not. Right An other alternative could be that we don't wait for packet back but that samba actually sends back the reply, doesn't make much difference. We have to wait for ntp to use event pooling as it will greatly ease the developpement of an async behavior, that is a todo of next version as far as I understand. Anyway, in either case I don't see a problem with giving the admin the option of enabling it in the config file. My point of view is we make it available by compiling it and leave up to the admin to activate it or not. We can in order to avoid problem not put this option in the ntp.conf so that only admins really willing to activate it will do (hopefully). Matthieu. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
