Discussion:
Bug#141507: sntop: 32 char hostname limit is wrong/evil
Add Reply
Petter Reinholdtsen
2025-01-20 07:20:01 UTC
Reply
Permalink
[Mark W. Eichin 2002-08-06]
I list a hostname of
krb5-verify-init-creds-opt-set-ap-req-nofail.krbtest.com
in my .sntoprc. strace shows that sntop silently trucates this, and
fails, running
I do not know the code, but had a look and suspect the limit is set
using the IN_BUF define. Here is a proof of concept patch increasing the limit:

diff --git a/sntop.h b/sntop.h
index 173cbdf..e5e35b9 100644
--- a/sntop.h
+++ b/sntop.h
@@ -14,7 +14,7 @@
*/

#define SNTOP_AUTHORS "Robert M. Love <***@tech9.net>, Chris M. Rivera <***@ufl.edu>"
-#define IN_BUF 33 /* size of our conf data vars and their input */
+#define IN_BUF 128 /* size of our conf data vars and their input */
#define CONF_BUF 256 /* size of path to conf data */
#define CONF_UFILE "/.sntoprc" /* name of user conf file .. we look for this in ~ first */
#ifndef CONF_SFILE

I agree that dropping the config file line read limit is a good idea,
but that would require a lot more rewriting than this simple oneliner.
As far as I can tell, the rest of sntop do not care about host name
lengths. Do you see a similar problem when passing the host name on
the command line? If I understand the code correctly, you should not.
Perhaps this issue can be fixed after 23 years?
--
Happy hacking
Petter Reinholdtsen
Mark Eichin
2025-01-21 00:00:01 UTC
Reply
Permalink
For a time-boxed effort, I believe 256 is better than 128 (RFC-1035
defines the limit in terms of wire-encoding of the DNS message rather
than the user-visible values (section 3.1, "To simplify
implementations") - there's also a 63 byte limit for "labels" but that's
just a single name-part and doesn't help here.)

(I don't currently have it installed so I don't have a handy answer to
your command line question.)
Petter Reinholdtsen
2025-01-21 13:10:01 UTC
Reply
Permalink
[Mark Eichin]
Post by Mark Eichin
For a time-boxed effort, I believe 256 is better than 128 (RFC-1035
defines the limit in terms of wire-encoding of the DNS message rather
than the user-visible values (section 3.1, "To simplify
implementations") - there's also a 63 byte limit for "labels" but that's
just a single name-part and doesn't help here.)
I do not disagree. Perhaps you can come up with a better patch? One
without a hardcoded limit would be even greater. :)
--
Happy hacking
Petter Reinholdtsen
Loading...