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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210927/f2568977/attachment.asc>
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 at 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 at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210930/9cafd38b/attachment.asc>