Difference in buffer behaviour between 8.89 and 8.9?
rsbecker at nexbridge.com
rsbecker at nexbridge.com
Thu Sep 7 23:05:15 AEST 2023
On Wednesday, September 6, 2023 11:49 PM, Damien Miller wrote:
>On Wed, 6 Sep 2023, rsbecker at nexbridge.com wrote:
>
>> On Thursday, May 19, 2022 5:21 PM, Scott Neugroschl wrote:
>> >Isn't that a consequence of the limits on the nonstop READX call?
>>
>> Yes it is an OS limit. I have been able to partially get this to work
>> as
>> follows:
>>
>> @@ -281,6 +281,10 @@ sshbuf_read(int fd, struct sshbuf *buf, size_t
>> maxlen, size_t *rlen)
>>
>> if (rlen != NULL)
>> *rlen = 0;
>> +#if defined (__TANDEM)
>> + if (maxlen > SSIZE_MAX)
>> + maxlen = SSIZE_MAX; // About 56Kb from limits.h #endif
>>
>> But I cannot figure out the best way to deal with the writes or the
>> most acceptable way to the OpenSSH team. Any suggestions?
>
>Is this true for all read() calls or just particular ones? If it's for all
read() calls, then
>maybe wrapping/replacing the read() function more generally would be
needed.
>
>channels.c isn't the only place in OpenSSH that might do a large read...
This is only for sshbuf_read at the moment, which got through most issues. I
could attempt the following that another project did:
What the git project did was create a compatibility layer with procs xread
and xwrite, with the same arguments as read/write, that allowed platform
handling to be tweaked. Not a small change, though. It would be easier if
there were defines that would be in place to guard this.
More information about the openssh-unix-dev
mailing list