| Summary: | Implement file copying in sftp server, use it to support rename across mount points | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | reuben.m |
| Component: | sftp-server | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED FIXED | ||
| Severity: | enhancement | CC: | djm, tj, vapier |
| Priority: | P2 | ||
| Version: | 5.2p1 | ||
| Hardware: | ix86 | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.mindrot.org/show_bug.cgi?id=2948 | ||
|
Description
reuben.m
2009-09-23 16:23:18 AEST
I realize that the sftp server was throwing an error because it can't rename across mount points. (Even though the bind mount in this case is sourced from the same partition, I assume there is no way for the server to know that) I'm using bind mounts to give different accounts, each with their own chroot, access to directories that need to be shared between specific accounts, but not with all accounts. So I want to append to this report a request for adding a copy command to the sftp server. I realize this is not part of the "official spec" but spec doesn't do me a bit of good when it prevents me from getting anything done. Make it an optional extension if you must. This will allow to move over mount points using copy + delete origional. -scp / ssh : will not work for me. I'm using a chroot sftp session that is locked down. I really don't like the idea of remote users in my scenario to be running commands not provided by the internal sftp server or anything that requires a shell. This is mainly for obvious security reasons since we are creating accounts for external clients our business deals with. -moving via copy-local : My users are dealing with huge media files. This is not a good idea. OR (Don't know why I didn't think of this earlier) just rework the rename function to detect when the user is trying to rename across a mount point and have it do a copy + delete original internally in those instances. I think it might be worthwhile to do a vendor extension to allow local copies on the server side, e.g. "cp@openssh.com" or somesuch. We could reuse this to implement fallback to copy either on the server or the client side. There is an old IETF Draft which proposed several SFTP extensions, including a 'copy-file' extension: http://tools.ietf.org/html/draft-ietf-secsh-filexfer-extensions-00 This extension is supported by the SmartFTP client and by the proftpd mod_sftp module. Thus perhaps using 'copy-file', rather than a vendor-specific extension, might be a slightly more generic approach. I like the idea of a draft standard that has already been implemented elsewhere. Might want to check an make sure the other implementations didn't deviate from the draft, or you could have an interoperability mess on your hands. i've filed bug 2948 and posted patches for implementing the "copy-data" sftp extension. it's a little lower level than "copy-file", but it's pretty trivial to implement a "cp" client command with open+copy+close ops. so maybe that's good enough ? sftp got a cp command via the copy-data extension in OpenSSH 9.0 Closing bugs from openssh-9.1 release cycle |