thr3ads.net - openssh bugs - [Bug 2949] New: "limits@openssh.com" extension to SFTP to query various transfer limits [Dec 2018]

If this information is useful, please help other people find it:
Share via:

bugzilla-daemon at bugzilla.mindrot.org

2018-Dec-29 10:19 UTC

[Bug 2949] New: "limits@openssh.com" extension to SFTP to query various transfer limits

https://bugzilla.mindrot.org/show_bug.cgi?id=2949

            Bug ID: 2949
           Summary: "limits at openssh.com" extension to SFTP to query
                    various transfer limits
           Product: Portable OpenSSH
           Version: -current
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sftp-server
          Assignee: unassigned-bugs at mindrot.org
          Reporter: vapier at gentoo.org

Created attachment 3218
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3218&action=edit
PROTOCOL v1

i haven't been able to find any prior art in this space.  if anyone is
familiar with a server/client implementing a relevant extension, feel
free to highlight it.

`sftp` has a -B option to set the transfer buffer size.  this applies
to both read & write SFTP packets.

when doing a read of a really large size, OpenSSH will respond with
short reads.  e.g. if you request 1MiB, the server will just respond
with 64KiB (sftp-server.c:process_read hardcodes buf[64*1024]).  this
leaves the client with expecting to chunk things up at one size, but
ends up having to backfill things dynamically.  the client is able to
recover though, so that's good.

when doing a write of a really large size, OpenSSH will just close the
connection as soon as it sees the header with the large write.  the
server hardcodes 256KiB (SFTP_MAX_MSG_LENGTH) and any attempt to write
anything larger than that is immediately rejected.  this is not
friendly and clients basically have to default to 32KiB all the time
and force users to manually select a size that they happen to know the
server they're connecting to supports.

if the server supports an extension to dynamically query the exact
limits the server imposes, the client can start with the 32KiB default,
and then automatically increase to something with better throughput.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

bugzilla-daemon at bugzilla.mindrot.org

2019-Jan-22 10:35 UTC

head link

[Bug 2949] "limits@openssh.com" extension to SFTP to query various transfer limits

https://bugzilla.mindrot.org/show_bug.cgi?id=2949

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
That seems reasonable, though some of these are only implicitly
defined. E.g. there is no internal limit to the max number of file
handles, sftp-server will just allocate up to the fd/heap rlimits.

So IMO there should be some way to express "unspecified" or
"unlimited"
(internally at least) limits. Maybe 0 for a limit?

Also, the values might as well be 64 bits.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

bugzilla-daemon at bugzilla.mindrot.org

2019-Feb-07 21:50 UTC

head link

[Bug 2949] "limits@openssh.com" extension to SFTP to query various transfer limits

https://bugzilla.mindrot.org/show_bug.cgi?id=2949

--- Comment #2 from Mike Frysinger <vapier at gentoo.org> ---
i tried to account for that here:> If the server doesn't enforce a specific limit, then the field may be
set to 0.
> This implies the server relies on the OS to enforce limits (e.g. available
> memory or file handles), and such limits might be dynamic.  The client
SHOULD
> take care to not try to exceed reasonable limits.
i think that covers it ?

wrt 32bit vs 64bit, i couldn't imagine a situation where a single
packet would hit that, but i guess if we're laying groundwork for a
protocol that will stick around for decades, might as well plan for
then rather than regret it.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

bugzilla-daemon at bugzilla.mindrot.org

2019-Feb-07 21:56 UTC

head link

[Bug 2949] "limits@openssh.com" extension to SFTP to query various transfer limits

https://bugzilla.mindrot.org/show_bug.cgi?id=2949

Mike Frysinger <vapier at gentoo.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3218|0                           |1
        is obsolete|                            |

--- Comment #3 from Mike Frysinger <vapier at gentoo.org> ---
Created attachment 3238
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3238&action=edit
PROTOCOL v1

change all the fields from uint32 to uint64

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

bugzilla-daemon at bugzilla.mindrot.org

2020-Jan-01 10:34 UTC

head link