[illumos-Developer] Webrev for bug 1102: Resource exhaustion in sftp client

Bayard Bell buffer.g.overflow at googlemail.com
Fri Jun 24 06:10:36 PDT 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24 Jun 2011, at 13:53, Gary Mills wrote:

> On Thu, Jun 23, 2011 at 04:03:18PM -0400, Albert Lee wrote:
>> On Thu, Jun 23, 2011 at 3:50 PM, Bayard Bell
>> <buffer.g.overflow at googlemail.com> wrote:
>>> On 23 Jun 2011, at 20:42, Gary Mills wrote:
>>>> 
>>>> According to the changelog for portable openssh, they're already
>>>> there:
>>>> 
>>>> 20110112
>>>>  - OpenBSD CVS Sync
>>>>    - nicm at cvs.openbsd.org 2010/10/08 21:48:42
>>>>      [openbsd-compat/glob.c]
>>>>      Extend GLOB_LIMIT to cover readdir and stat and bump the malloc limit
>>>>      from ARG_MAX to 64K.
>>>>      Fixes glob-using programs (notably ftp) able to be triggered to hit
>>>>      resource limits.
>>>>      Idea from a similar NetBSD change, original problem reported by jasper at .
>>>>      ok millert tedu jasper
>>>> 
>>>> So, once the ssh product is updated from upstream, their resource
>>>> limit fixes will be present.
>>> 
>>> There isn't any simple pull from upstream for ssh, as SUNWssh is a
>>> somewhat different creature than openssh-portable.
>> 
>> Trying to sync with openssh-portable will be a much larger endeavour
>> than the scope of this issue.
> 
> I wonder if the SUNWssh changes could be submitted upstream.  That might
> be a way to get us in sync again.

I doubt that'll go anywhere. The most substantive change in SUNWssh proceeds from a critique of how openssh-portable changes the monitor's role in privsep (ironically, the objection is that it would make the monitor an oracle), whereas privsep seems something of a totem for openssh (that's not to say that it isn't an innovation). I can go back to see if anything happened on the public mailing lists, but I suspect that an approach was already made on this issue, whether on a public list or not.

Moreover, I've spent a little bit of time browsing the openssh-portable issue tracker to understand the status of LPK-like functionality, and what that makes remarkably clear is that the openssh developers are relatively few in number and have chosen to focus on a relatively narrow range of issues, leaving some patches in limbo for years at a time, even where there is clearly demand from various distros. Which is to say: even if they were receptive to the SUNWssh changes, it might be years before the patches were accepted. On the other hand there are areas where SUNWssh hasn't tracked substantial feature advancement, so the downside of effectively forking has been neglect. I've entered maybe two RFEs already for bringing in standardised (SSHFP in DNS) or in-demand (LPK-like) features, and there's some code from Joyent that can be pulled to provide a basis for the latter.

Unless there's a strong feeling that Illumos ssh should be based off openssh-portable, with SUNWssh dumped, it probably makes more sense to root out code like globbing that comes from OpenBSD compatibility libraries and move to Illumos-based libraries, thus reducing duplicative code. IOW: if we're going to maintain it, we might as well make it maintainable.

Cheers,
Bayard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)

iQIcBAEBAgAGBQJOBIzeAAoJEHm5cBpJ87doPPMP/2fpKzmTBX8WT/EOJ4Y8RIu1
0UabQCyKVh7QBjvUaz8kblrRYSL+2frk54eyZXx2C6PIq07q7FrQCxlBKCQoxAwJ
61Mv3EQbzfVxqsatGDQQf43CCmt/Mu2rVtO5CkBKg3RkqM/iq75cWeYuMAbabINP
9ycH8bM8avP7j3DKIrAVefq18dMj7sL3OhIgS86W2WtOhMso6RdSuIT0Ba3dbrA0
yhIS0F+4u65ThDzASdvaT4K2JsONfSaCEtLuWaithjSNaLwDsINVAirzoKOVzMF3
P8f5126ajs7bcSXkmKvSBZYTpR2sRAIf3gOd9XBW5EzS/LIMmLt7/Q7iD8Squb5k
JWcgc5CtB597BlBdrdr4n0EKVwBiVnIMUziPPpItsrh8rTgOjPJyGCheK5MOrUQi
68R4nTd5O8DWRvPzbGZYIFNYvY7tDcVtcXrD/iAi0KgIWCf8h5ylmk02yYeiZz/i
JIvFsrInenSh2yjXSqf4anyq2L2gTNqjc7IMC5gHDvZuXxM/zy5ga+I782Mwm7vA
s+BrOAPQDrukqyWayrZcXXUHqe6xHSYXBFLL8Z3mZifI4IgIq4I9BVpunYvW3DNh
ANHTPWvaYEyfBhMzug7OHxFywf3FUFwjek0VCsbQp3q96t4lpTTVVtcJ8jebGorE
XMx6b9QVdhne9cRVHBLc
=9UbU
-----END PGP SIGNATURE-----



More information about the Developer mailing list