Yes, and — a qualified — no. (Qualified because there is always a *chance*
I or another implementor could screw this up. But I don’t see a problem
with the design at least.)
On Tue, Dec 19, 2017 at 2:13 PM Karan, Cem F CIV USARMY RDECOM ARL (US) <
cem.f.karan.civ@xxxxxxxx> wrote:
Two questions:
- Can it be made compile-time configurable? That way the same codebase
can be used on highly limited embedded systems, as well as highly capable
laptops/desktops/servers (modulo the requirement users remember that they
can't use certain paths on certain systems)
- Is there any chance that this will cause a security issue of some type
(e.g. buffer overflow that leads to a stack smash or other attack)?
Thanks,
Cem Karan
------------------------------
*From:* nanomsg-bounce@xxxxxxxxxxxxx [nanomsg-bounce@xxxxxxxxxxxxx] on
behalf of Garrett D'Amore [garrett@xxxxxxxxxx]
*Sent:* Tuesday, December 19, 2017 5:01 PM
*To:* nanomsg@xxxxxxxxxxxxx
*Subject:* [Non-DoD Source] [nanomsg] increasing the maximum socket
address length
Today we have a fairly arbitrary limit on socket address lengths of 128
bytes. This is actually pretty unfortunate, since it can be badly
constraining in some circumstances:
* DNS names can be up to 253 bytes (255 minus some encoding details per
RFC 1035)
* IPC paths can live anywhere, modern filesystems support much longer path
lengths (POSIX requires PATH_MAX at least 256).
* With websocket, URLs could have long PATH-INFO (and later query
parameters?)
I’d like to propose increasing this to at least 512 bytes. I can’t really
see a need to go to 1K, but I’d support that too… (One advantage for
smaller path limits is that some implementations use automatic buffers to
hold these — so you wind up with that thing on a stack. If you have tiny
stacks — like 8K — this can be challenging.)
The other effect of changing this limit is that some older implementations
might not be able to communicate with new implementations with a longer
path limit, if they are actually using the longer limit.
I don’t see a problem with changing this — but wanted to give folks a
chance to chime in.
- Garrett
