Bug 3318 - Read-only mode broken by limits@openssh.com extension
Summary: Read-only mode broken by limits@openssh.com extension
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sftp-server (show other bugs)
Version: 8.6p1
Hardware: Other Linux
: P5 major
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_8_7
  Show dependency treegraph
 
Reported: 2021-06-06 09:34 AEST by Hector Martin
Modified: 2022-02-25 13:57 AEDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hector Martin 2021-06-06 09:34:40 AEST
limits@openssh.com is marked as does_write=1, which causes the client to break when the request is denied, printing a cryptic error message.

$ sftp <server...>
Expected SSH2_FXP_EXTENDED_REPLY(201) packet, got 101

It's really hard to get logs out of the server in internal-chroot mode, but strace shows:

[pid 133138] write(2, "Refusing limits request in read-only mode\r\n", 43) = 43

I don't see why the extension should be restricted in read-only mode. The client should probably also not just break and abort when this happens.
Comment 1 Damien Miller 2021-06-06 13:04:45 AEST
Marking the limits extension as needing write is indeed a bug, but the extension should simply not be offered in this case. E.g.

> Refusing limits request in read-only mode
> debug2: compose_extension: refusing to advertise disallowed extension limits@openssh.com

And the client should therefore never request it.

How is your sftp-server configured?
Comment 2 Damien Miller 2021-06-06 13:14:20 AEST
btw you can get more logs from sftp-server by putting "-l debug3" on it's command-line arguments in sshd_config, though you may need to adjust your syslog configuration to accept debug messages.
Comment 3 Damien Miller 2021-06-06 13:26:15 AEST
anyway, I have fixed the server bug that caused limits@ to be considered a write operation and have made the client degrade gracefully when the server advertises but fails to accept it.

I'd really like to understand how you hit this condition though, as it might be an indication of another bug there.
Comment 4 Hector Martin 2021-06-06 16:50:15 AEST
Argh, you're right. What happened is the server is 8.5p1. I was very confused, because limits was mentioned in the release notes fir 8.6. It seems this is a mistake in the release notes; the feature was already in the server in 8.5p1, just buggier. 8.5p1 does *not* do the check before advertising extensions, it just unconditionally advertises them all, hence the problem.

The 8.6p1 client's new support then made this visible, and I confused myself with the release notes (and I thought I had upgraded the server already), since why would a non-8.6 server advertise a feature that the release notes claim was introduced in 8.6? :-)

Indeed the issue does not happen with 8.6 -> 8.6, just 8.6 -> 8.5.
Comment 5 Damien Miller 2021-06-06 18:33:21 AEST
ah, that makes more sense - sftp-server in openssh 8.5 didn't filter advertisements based on its configuration. Thanks for chasing it down.

Anyway, both the client and server side are fixed now. Updating the server to 8.6 works around the problem too because it will refuse to advertise it in read-only mode.
Comment 6 Damien Miller 2022-02-25 13:57:59 AEDT
closing bugs resolved before openssh-8.9