Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request attributes are not being propagated for SSH_FXP_OPEN operation #557

Open
pavan-aeturi opened this issue Sep 8, 2023 · 5 comments

Comments

@pavan-aeturi
Copy link

Hi Team, I'm facing the below issue where I'm looking for ways to block interrupted uploads (similar issue). So I want to access request attributes such as file-size during a put command. Even though the client sends the attributes during a put command, sftp-go server library doesn't seem to propagate it to handler

The restriction might be intentional and have a good reason behind it, in which case may I know the details of the reasoning? The library specification document too, doesn't talk about having this restriction. Please correct me if I'm wrong. Thanks in the advance.

Screenshot 2023-09-08 at 2 03 28 PM

`// New Request initialized based on packet data
func requestFromPacket(ctx context.Context, pkt hasPath, baseDir string) *Request {
request := &Request{
Method: requestMethod(pkt),
Filepath: cleanPathWithBase(baseDir, pkt.getPath()),
}
request.ctx, request.cancelCtx = context.WithCancel(ctx)

switch p := pkt.(type) {
case *sshFxpOpenPacket:
	request.Flags = p.Pflags
case *sshFxpSetstatPacket:
	request.Flags = p.Flags
	request.Attrs = p.Attrs.([]byte)
case *sshFxpRenamePacket:
	request.Target = cleanPathWithBase(baseDir, p.Newpath)
case *sshFxpSymlinkPacket:
	// NOTE: given a POSIX compliant signature: symlink(target, linkpath string)
	// this makes Request.Target the linkpath, and Request.Filepath the target.
	request.Target = cleanPathWithBase(baseDir, p.Linkpath)
	request.Filepath = p.Targetpath
case *sshFxpExtendedPacketHardlink:
	request.Target = cleanPathWithBase(baseDir, p.Newpath)
}
return request

} `

@puellanivis
Copy link
Collaborator

There are unfortunately known issues with the opening of files and handling of attributes. I’ve done a complete rewrite of the client before, but due to early design decisions some of these just aren’t possible to address.

Though… in this case, :squint: it might be possible to bodge in request.Attrs if we make sure the sshFxpOpenPacket contains them at least.

@drakkan
Copy link
Collaborator

drakkan commented Sep 8, 2023

If a client sends size 0 because it does not support this optional attribute it will be difficult to distinguish it from clients that support the attribute if they upload a 0 byte file

@puellanivis
Copy link
Collaborator

Wouldn’t a client that does not support the optional attribute just not even set SSH_FILEXFER_ATTR_SIZE and thus be distinct from those that do support the attribute?

@pavan-aeturi
Copy link
Author

yes @puellanivis, that makes sense, SSH_FILEXFER_ATTR_SIZE check should help figure out if it is actually set and something like the below should help resolve file-size on server side

// r *sftp.Request
if r.AttrFlags().Size && r.Attributes() != nil && r.Attributes().Size > 0 {
  h.logger.Info("File size of upload file_length: %d", r.Attributes().Size)
}

@mafredri
Copy link
Contributor

mafredri commented Dec 12, 2023

I ended up implementing attrs for the old Server in #567, should be possible to use in the request server as well, I think. There are probably edge cases I haven't considered, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants