Bug 3318

Summary:	Read-only mode broken by limits@openssh.com extension
Product:	Portable OpenSSH	Reporter:	Hector Martin <marcan>
Component:	sftp-server	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED FIXED
Severity:	major	CC:	djm
Priority:	P5
Version:	8.6p1
Hardware:	Other
OS:	Linux
Bug Depends on:
Bug Blocks:	3302

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