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@xxxxxxxxxxx", 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@xxxxxxxxxxx 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@xxxxxxxxxxx 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@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
