Re: is SFTPv4 support possible?

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@xxxxxxxxxx>:
>
> 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@xxxxxxxxxxx
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux