Mailing List Archive

is SFTPv4 support possible?
would SFTPv4 support be acceptable in OpenSSH's server & client ?

SFTPv4 supports higher stat fidelity & user/group names (not just numeric):
https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-04#section-10.1

iiuc, some of the newer features are a bit contentious, like the NFS ACL models
(which only get worse it seems with SFTPv5 & SFTPv6). from a quick scan, it
seems these only show up in the file attrs operations, and the server could
just not return any (never set SSH_FILEXFER_ATTR_ACL). if the client were to
set file attrs and they have SSH_FILEXFER_ATTR_ACL set, then the server could
also ignore it, or have it return SSH_FX_OP_UNSUPPORTED.

the other feature that looks a bit dicey is opening files in text mode. the
caveats the spec sprinkles around makes it sound like it too would be easier
to simply return SSH_FX_OP_UNSUPPORTED.

requiring filenames be UTF-8 sounds fine ... the code already treats paths as
a series of bytes (effectively ignoring the encoding), so can just keep doing
that. if the client sends invalid UTF-8, that's a client bug. if the server
has a path that is invalid UTF-8, then the client can decide to ignore it, or
process it.

everything else looks pretty straight forward.
-mike
Re: is SFTPv4 support possible? [ In reply to ]
Hi,
the higher versions (like 6) have a supported structure with all the
flags and features the servers support, see:

https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-5.4

The server can simply set the valid attributes like size, permissions,
type, owner and group and times, and so thus ignoring everything else.

But the standard answer is use a different sftp subsystem than the one
provided by openssh. I'm writing one which supports at least version
6, and possibly uses some extensions.

See for example:

https://www.greenend.org.uk/rjk/sftpserver/

There is a lot of info about sftp implementations.
Stef Bon

Op ma 27 sep. 2021 om 10:56 schreef Mike Frysinger <vapier@gentoo.org>:
>
> would SFTPv4 support be acceptable in OpenSSH's server & client ?
>
> SFTPv4 supports higher stat fidelity & user/group names (not just numeric):
> https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-04#section-10.1
>
> iiuc, some of the newer features are a bit contentious, like the NFS ACL models
> (which only get worse it seems with SFTPv5 & SFTPv6). from a quick scan, it
> seems these only show up in the file attrs operations, and the server could
> just not return any (never set SSH_FILEXFER_ATTR_ACL). if the client were to
> set file attrs and they have SSH_FILEXFER_ATTR_ACL set, then the server could
> also ignore it, or have it return SSH_FX_OP_UNSUPPORTED.
>
> the other feature that looks a bit dicey is opening files in text mode. the
> caveats the spec sprinkles around makes it sound like it too would be easier
> to simply return SSH_FX_OP_UNSUPPORTED.
>
> requiring filenames be UTF-8 sounds fine ... the code already treats paths as
> a series of bytes (effectively ignoring the encoding), so can just keep doing
> that. if the client sends invalid UTF-8, that's a client bug. if the server
> has a path that is invalid UTF-8, then the client can decide to ignore it, or
> process it.
>
> everything else looks pretty straight forward.
> -mike
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: is SFTPv4 support possible? [ In reply to ]
On Mon, 27 Sep 2021, Mike Frysinger wrote:

> would SFTPv4 support be acceptable in OpenSSH's server & client ?
>
> SFTPv4 supports higher stat fidelity & user/group names (not just numeric):
> https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-04#section-10.1
>
> iiuc, some of the newer features are a bit contentious, like the NFS ACL models
> (which only get worse it seems with SFTPv5 & SFTPv6). from a quick scan, it
> seems these only show up in the file attrs operations, and the server could
> just not return any (never set SSH_FILEXFER_ATTR_ACL). if the client were to
> set file attrs and they have SSH_FILEXFER_ATTR_ACL set, then the server could
> also ignore it, or have it return SSH_FX_OP_UNSUPPORTED.
>
> the other feature that looks a bit dicey is opening files in text mode. the
> caveats the spec sprinkles around makes it sound like it too would be easier
> to simply return SSH_FX_OP_UNSUPPORTED.
>
> requiring filenames be UTF-8 sounds fine ... the code already treats paths as
> a series of bytes (effectively ignoring the encoding), so can just keep doing
> that. if the client sends invalid UTF-8, that's a client bug. if the server
> has a path that is invalid UTF-8, then the client can decide to ignore it, or
> process it.
>
> everything else looks pretty straight forward.

How many of these things could be implemented as extensions?

AFAIK we could use SSH_FILEXFER_ATTR_EXTENDED extensions to send
nanosecond timestamps as well as user/group names, and it should be
backwards compatible...

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: is SFTPv4 support possible? [ In reply to ]
On Tue, 28 Sep 2021, Stef Bon wrote:

> Hi,
> the higher versions (like 6) have a supported structure with all the
> flags and features the servers support, see:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-5.4

This is true for v3 too, it's just that v3 doesn't have flags for
everything that later versions do. It does have an extension mechanism
though...

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: is SFTPv4 support possible? [ In reply to ]
On 29 Sep 2021 12:35, Damien Miller wrote:
> On Mon, 27 Sep 2021, Mike Frysinger wrote:
> > would SFTPv4 support be acceptable in OpenSSH's server & client ?
> >
> > SFTPv4 supports higher stat fidelity & user/group names (not just numeric):
> > https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-04#section-10.1
> >
> > iiuc, some of the newer features are a bit contentious, like the NFS ACL models
> > (which only get worse it seems with SFTPv5 & SFTPv6). from a quick scan, it
> > seems these only show up in the file attrs operations, and the server could
> > just not return any (never set SSH_FILEXFER_ATTR_ACL). if the client were to
> > set file attrs and they have SSH_FILEXFER_ATTR_ACL set, then the server could
> > also ignore it, or have it return SSH_FX_OP_UNSUPPORTED.
> >
> > the other feature that looks a bit dicey is opening files in text mode. the
> > caveats the spec sprinkles around makes it sound like it too would be easier
> > to simply return SSH_FX_OP_UNSUPPORTED.
> >
> > requiring filenames be UTF-8 sounds fine ... the code already treats paths as
> > a series of bytes (effectively ignoring the encoding), so can just keep doing
> > that. if the client sends invalid UTF-8, that's a client bug. if the server
> > has a path that is invalid UTF-8, then the client can decide to ignore it, or
> > process it.
> >
> > everything else looks pretty straight forward.
>
> How many of these things could be implemented as extensions?
>
> AFAIK we could use SSH_FILEXFER_ATTR_EXTENDED extensions to send
> nanosecond timestamps as well as user/group names, and it should be
> backwards compatible...

hmm, if we're thinking outside the box ...

one thought i had but figured would be rejected was that we'd backport the new
SSH_FILEXFER_ATTR_OWNERGROUP to SFTPv3 (as it's backwards compatible), but that
might work OK for client->server, but not so well for server->client (since the
spec makes it sound like flags must be within the defined range only). so lets
forget about this avenue.

another idea was that we'd define an extension whereby the client could upgrade
its connection (akin to HTTP upgrading to 1.1 or 2.0). the server would have
"sftpv4-file-attrs@openssh.com", and if the client sent that request, then all
file attrs would have to use the newer SFTPv4 form for the rest of the session.
i think this is still within the SFTPv3 spec and wouldn't break anyone. it has
the slight advantage of the types being directly encoded.

otherwise, i think your idea would also work within the SFTPv3 spec and not
break anyone. it would mean servers & clients would have to serialize to
strings everywhere, but maybe that's not a big deal. the standard & extension
fields would have to both be specified, and the other side would ignore the
standard data when it sees the extension. e.g. the uid & gid fields would have
to be specified, but if the username & group extensions were include, they'd be
ignored in favor of dynamic lookup.

rough sketch of extensions i'd be interested in:
* attrs-type@openssh.com - the possible file types from stat/getdents:
"block" "char" "dir" "fifo" "link" "reg" "socket" "unknown"
* attrs-owner@openssh.com - the username as a string (instead of uid)
* attrs-group@openssh.com - the groupname as a string (instead of gid)
* attrs-atime-sec@openssh.com - the 64-bit access time (if 32-bit overflows)
* attrs-mtime-sec@openssh.com - the 64-bit modify time (if 32-bit overflows)
* attrs-ctime-sec@openssh.com - the 64-bit status time
* attrs-btime-sec@openssh.com - the 64-bit create time
* attrs-atime-nsec@openssh.com - the subsecond access time (for nanoseconds)
* attrs-mtime-nsec@openssh.com - the subsecond modify time (for nanoseconds)
* attrs-ctime-nsec@openssh.com - the subsecond status time (for nanoseconds)
* attrs-btime-nsec@openssh.com - the subsecond create time (for nanoseconds)

maybe instead of "btime" we should use "createtime" as that would match newer
SFTP specs better instead of matching Linux's statx field.

i opting for separate sec fields here to make parsing a bit easier. i figure
doing strtoull on an entire string is easier than finding the . separator and
parsing the numbers before/after that. sscanf(buf, "%llu.%llu", &sec, &nsec).

lmk if you have a preference on the route to take.
-mike
Re: is SFTPv4 support possible? [ In reply to ]
Op wo 29 sep. 2021 om 08:10 schreef Damien Miller <djm@mindrot.org>:
>
> On Tue, 28 Sep 2021, Stef Bon wrote:
>
> This is true for v3 too, it's just that v3 doesn't have flags for
> everything that later versions do. It does have an extension mechanism
> though...
>

No, there is no "supported" structure included in the packet the
server sends for version 3 and 4. only 5 and 6, see:

https://www.greenend.org.uk/rjk/sftp/sftpversions.html

The extensions are the same for all versions.

Stef
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: is SFTPv4 support possible? [ In reply to ]
Op wo 29 sep. 2021 om 08:34 schreef Mike Frysinger <vapier@gentoo.org>:
>
> On 29 Sep 2021 12:35, Damien Miller wrote:

> > AFAIK we could use SSH_FILEXFER_ATTR_EXTENDED extensions to send
> > nanosecond timestamps as well as user/group names, and it should be
> > backwards compatible...
>
> hmm, if we're thinking outside the box ...
>
> one thought i had but figured would be rejected was that we'd backport the new
> SSH_FILEXFER_ATTR_OWNERGROUP to SFTPv3 (as it's backwards compatible), but that
> might work OK for client->server, but not so well for server->client (since the
> spec makes it sound like flags must be within the defined range only). so lets
> forget about this avenue.
>
> another idea was that we'd define an extension whereby the client could upgrade
> its connection (akin to HTTP upgrading to 1.1 or 2.0). the server would have
> "sftpv4-file-attrs@openssh.com", and if the client sent that request, then all
> file attrs would have to use the newer SFTPv4 form for the rest of the session.
> i think this is still within the SFTPv3 spec and wouldn't break anyone. it has
> the slight advantage of the types being directly encoded.
>
> otherwise, i think your idea would also work within the SFTPv3 spec and not
> break anyone. it would mean servers & clients would have to serialize to
> strings everywhere, but maybe that's not a big deal. the standard & extension
> fields would have to both be specified, and the other side would ignore the
> standard data when it sees the extension. e.g. the uid & gid fields would have
> to be specified, but if the username & group extensions were include, they'd be
> ignored in favor of dynamic lookup.
>
> rough sketch of extensions i'd be interested in:
> * attrs-type@openssh.com - the possible file types from stat/getdents:
> "block" "char" "dir" "fifo" "link" "reg" "socket" "unknown"
> * attrs-owner@openssh.com - the username as a string (instead of uid)
> * attrs-group@openssh.com - the groupname as a string (instead of gid)
> * attrs-atime-sec@openssh.com - the 64-bit access time (if 32-bit overflows)
> * attrs-mtime-sec@openssh.com - the 64-bit modify time (if 32-bit overflows)
> * attrs-ctime-sec@openssh.com - the 64-bit status time
> * attrs-btime-sec@openssh.com - the 64-bit create time
> * attrs-atime-nsec@openssh.com - the subsecond access time (for nanoseconds)
> * attrs-mtime-nsec@openssh.com - the subsecond modify time (for nanoseconds)
> * attrs-ctime-nsec@openssh.com - the subsecond status time (for nanoseconds)
> * attrs-btime-nsec@openssh.com - the subsecond create time (for nanoseconds)
>
> maybe instead of "btime" we should use "createtime" as that would match newer
> SFTP specs better instead of matching Linux's statx field.
>
> i opting for separate sec fields here to make parsing a bit easier. i figure
> doing strtoull on an entire string is easier than finding the . separator and
> parsing the numbers before/after that. sscanf(buf, "%llu.%llu", &sec, &nsec).
>

What are you doing? You are reinventing SFTP. The features you want
are in the higher versions of SFTP. Just start supporting versions
higher than 3, and you are there.
And openssh is not the only server and client.

Stef
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: is SFTPv4 support possible? [ In reply to ]
On Wed, 29 Sep 2021, Stef Bon wrote:

> What are you doing? You are reinventing SFTP. The features you want
> are in the higher versions of SFTP. Just start supporting versions
> higher than 3, and you are there. And openssh is not the only server
> and client.

"just" implementing later sftp revisions means promising to support all
the mandatory features in them, as well as providing compatibility for
the current version.

The sftp standardisation process was a trainwreck of accepting poorly-
justified features that made the later versions of the protocol bloated
and unwieldy. OpenSSH jumped off the train fairly early and have no
desire to get back on it.

So, we've been demonstrably willing to consider extensions that fill in
missing information for _well-justified_ use-cases (e.g. the statvfs
extension doesn't even exist in later filexfer drafts) , but have no
desire to adopt the whole mess that protocol became.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: is SFTPv4 support possible? [ In reply to ]
On Wed, 29 Sep 2021, Mike Frysinger wrote:

> > How many of these things could be implemented as extensions?
> >
> > AFAIK we could use SSH_FILEXFER_ATTR_EXTENDED extensions to send
> > nanosecond timestamps as well as user/group names, and it should be
> > backwards compatible...
>
> hmm, if we're thinking outside the box ...
>
> one thought i had but figured would be rejected was that we'd backport
> the new SSH_FILEXFER_ATTR_OWNERGROUP to SFTPv3 (as it's backwards
> compatible), but that might work OK for client->server, but not so
> well for server->client (since the spec makes it sound like flags must
> be within the defined range only). so lets forget about this avenue.
>
> another idea was that we'd define an extension whereby the client
> could upgrade its connection (akin to HTTP upgrading to 1.1 or 2.0).
> the server would have "sftpv4-file-attrs@openssh.com", and if the
> client sent that request, then all file attrs would have to use the
> newer SFTPv4 form for the rest of the session. i think this is still
> within the SFTPv3 spec and wouldn't break anyone. it has the slight
> advantage of the types being directly encoded.

Well, I guess there are three broad extension approaches for file
attributes:

1. Define all the additional attributes as SSH2_FILEXFER_ATTR_EXTENDED
extensions.

2. What you suggest above: have some modal extension that selected
sftp v>3 attribute encoding to get the additional attributes.

3. Have some extension that allows the client and server to negotiate
extended members in the attribute flags bitmask.

#1 has the advantage of being completely backwards compatible without
needing a negotiation mechanism. OTOH it's pretty heavy on the wire,
with even a single byte attribute needing a whole qualified name to
encode it.

I think #2 would make sense if we had a desire to move in the direction
of later protocol versions in the future. We don't - IMO the later
versions are at best a mixed bag of some desirable features and a lot
of junk.

#3 is basically #1 with most of the overhead removed (at the cost of
an additional thing that the client and server have to agree on)

For some things, #1 definitely makes the most sense - a number of
the things that you ask for can be considered extended information
that relates to attribute flags that already exist. For example,
we could send a filetimes@openssh.com extension that included
nanosecond times and ctime whenever we send an attribute with
SSH2_FILEXFER_ATTR_ACMODTIME.

I'm not 100% sure what the best approach for owner/group is
though. One one hand, we could send it as an extension whenever
SSH2_FILEXFER_ATTR_UIDGID is sent, but that is a lot of extra
information. Would a user/group-lookup@openssh.com extension work
better? That would allow the client to incur the cost only once for each
user/group resolved during a session (assuming the client implements a
cache).

Implementing these as lookup extensions has the side benefit of allowing
administrators to turn it off via the existing request denylisting
feature, as I expect a few will want to do.

For file type, can't you already infer this from the higher bits of
SSH2_FILEXFER_ATTR_PERMISSIONS? sftp-server doesn't filter them
from what stat(2) returns. I guess we could advertise this fact to make
it clear to clients that they can be relied upon...

-d

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: is SFTPv4 support possible? [ In reply to ]
Op do 30 sep. 2021 om 00:53 schreef Damien Miller <djm@mindrot.org>:
>

>
> "just" implementing later sftp revisions means promising to support all
> the mandatory features in them, as well as providing compatibility for
> the current version.

Supporting different versions is not that hard. I've written a sftp
client (and busy writing a sftp subsystem) supporting all versions,
and a lot of the callbacks are the same. In my client the receive and
send operations are in an array, which differs per version, and a lot
of them are the same. See for example:

https://github.com/stefbon/OSNS/blob/main/src/sftp/send/send-v03.c
https://github.com/stefbon/OSNS/blob/main/src/sftp/send/send-v06.c

The parsing and setting of attributes is similar. Most important are
the change from uid/gid to owner and group in "user@domain" format,
the possibility of adding subseconds, and c(hange)time.

You say you have to support all mandatory features, that is not so.
They are voluntary, where a basic set (like size, permissions, times
and owner/group) is very advisable. The construction with the
"supported" structure in versions 5 and 6 is designed for that goal:
just set the attributes you want to support, and ignore everything you
do not want to like the ACL's, the mimetype and the untranslated name
for example in the attributes. This also counts for the open flags
(like (b)locks, text mode)

So if you have experienced those new features as mandatory, yes then
it's too much I can imagine, but they are not.

>
> The sftp standardisation process was a trainwreck of accepting poorly-
> justified features that made the later versions of the protocol bloated
> and unwieldy. OpenSSH jumped off the train fairly early and have no
> desire to get back on it.
>

Well there were a lot of things added, but you do not have to support
those. And the stat function in versions higher than version 3 is much
much better than in version 3.

> So, we've been demonstrably willing to consider extensions that fill in
> missing information for _well-justified_ use-cases (e.g. the statvfs
> extension doesn't even exist in later filexfer drafts) , but have no
> desire to adopt the whole mess that protocol became.

No I do not agree that the protocol has become a mess. Just take
out/support the things which have been improved (I've mentioned before
using the supported structure in the version packet) and there you go.

I'm thinking about adding some extensions myself like:

map-extension@osns.net: map a name to a code between 210 and 255, with
the sftp protocol it is possible to assign an opcode to a name, which
will prevent an expensive name lookup in a linked list.

opendir@osns.net: add a valid parameter to tell the server the
attributes it may send back in a readdir. With a FUSE fs, after the
readdir provides a dentry, a lookup is done. That way the readdir does
not have to provide attributes, only the type and the name. With the
current versions both readdir and lookup (=stat) provide attributes
like size, perm, times and ownergroup, which is double. A valid
parameter in the opendir call makes it also possible to support the
readdirplus call, which is a readdir and lookup in one, where the
client (=FUSE fs) just wants to receive all the desired attributes in
one.
I also have been thinking about a flag and mask in the opendir to add
a fs change watch to a directory to the opendir call: after the
readdir has finished the directory is still watched on the server and
changes according to the mask are sent to the client. This is only a
bit difficult, since the SFTP protocol uses a request-response model
(using an unique id per request), and the server sending back fs
events will be a reply to the original opendir request. Only very
basic events like add, delete and change attributes of a child entry,
as well as (re)move of the directory the watch is on.

Anyway, what I want to say is that supporting the new versions is not that hard.

Stef Bon

https://github.com/stefbon/OSNS
https://osns.net/
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: is SFTPv4 support possible? [ In reply to ]
i decided to look at what SFTPv4 would actually look like were it implemented.
tbh, if we only do the server, i don't think it's really that bad, especially
when we compare it to implementing custom extensions (vs the status quo). if
anything, i think doing SFTPv4 is better code-wise than doing extensions.

supporting it in the client requires more work, so maybe we don't bother there,
at least initially ? i'll send a partial (like 90% done) implementation.

wdyt ? i'll send patches for illustration.
-mike
Re: is SFTPv4 support possible? [ In reply to ]
On Thu, 30 Sep 2021, Mike Frysinger wrote:

> i decided to look at what SFTPv4 would actually look like were it implemented.
> tbh, if we only do the server, i don't think it's really that bad, especially
> when we compare it to implementing custom extensions (vs the status quo). if
> anything, i think doing SFTPv4 is better code-wise than doing extensions.

IMO the question remains: why?

Specifcally, what use-cases do each of these things enable?

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: is SFTPv4 support possible? [ In reply to ]
On 07 Oct 2021 17:08, Damien Miller wrote:
> On Thu, 30 Sep 2021, Mike Frysinger wrote:
> > i decided to look at what SFTPv4 would actually look like were it implemented.
> > tbh, if we only do the server, i don't think it's really that bad, especially
> > when we compare it to implementing custom extensions (vs the status quo). if
> > anything, i think doing SFTPv4 is better code-wise than doing extensions.
>
> IMO the question remains: why?
>
> Specifcally, what use-cases do each of these things enable?

i outlined this in the patch series i sent out ... but i'll summarize even
more here. here are SFTPv3 problems that SFTPv4 solves.

SFTPv3 is going to break in 2038 due to 32-bit timestamps.
SFTPv3 is limited to seconds granularity (no-subseconds).
SFTPv3 only supports numeric uid/gid, so can't do "chown vapier" and let
the server resolve the names.
SFTPv3 does not support birthtime stat.

and to reiterate, supporting SFTPv4 does not require ACL processing of any
sort. there is a single "acl" string in the file attributes, but there is
no requirement that the server/client send it, or even process it. so my
patches ignore it.

which means supporting SFTPv4 in the server comes down to:
(1) reworking file attributes parsing
(2) skipping the "longname" field that was removed from a bunch of messages

if we were to design our own set of extensions on top of SFTPv3, we'd have
to basically do (1) anyways, so just supporting SFTPv4 instead seems like
a better route to take.
-mike