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

[Gary Mills]

On Fri, Jun 24, 2011 at 02:10:36PM +0100, Bayard Bell wrote:
> 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:
> >>> 
> >>> 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.

I've heard about that long-standing disagreement before.

> 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.

This situation is quite unfortunate.

> 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.

Yes, SUNWssh is in need of improvements.  I'm not the one to make
them, however.  I use `ssh' lightly, preferring `rlogin' and friends.
I'm not familiar with the nuances of `ssh'.

> 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.

Yes, I agree with this direction.  The Illumos glob(3c) library also
needs improvement.  The difficult part is to maintain binary
compatibility so that existing programs still work.  The existing
library is strictly POSIX.  The function prototype is unchanged in
non-POSIX mode, but more flags are available, the flag defaults
change, and the size of the glob_t structure increases.  In
particular, the meaning of zero in the flags argument changes.  The
library somehow needs to detect if glob() is being called in POSIX or
non-POSIX mode.  Too bad it can't simply determine the size of the
structure provided by the caller.

-- 
-Gary Mills-        -Unix Group-        -Computer and Network Services-