disabling local-to-local transfers?

[Brian Candler]

On 26/07/2026 08:20, Philipp Marek wrote:
> "scp" as protocol is deprecated in favour of sftp anyway.

Yes, so "scp" as a command is now primarily a convenient frontend to sftp.


>
> Yeah, it just runs the "cp" binary with a few options,

That's an interesting observation.  In principle, you could use 
something like AppArmor to prevent scp running cp, or a library shim 
which intercepts execvp().  But doing that would be inconvenient across 
multiple platforms. e.g. I use macOS as a client a lot these days, and I 
have no idea what the equivalent features are.

I now also understand why scp doesn't read any config file: it spawns 
the ssh binary, and that binary reads the ssh config file.


>
> (Simply adding "-a", "--preserve", or whatever runs
> into compatibility problems again, so that's not an option ;)

It does add "-p" if requested:

                 if (!host) {    /* Local to local. */
                         freeargs(&alist);
                         addargs(&alist, "%s", _PATH_CP);
                         if (iamrecursive)
                                 addargs(&alist, "-r");
                         if (pflag)
                                 addargs(&alist, "-p");
                         addargs(&alist, "--");
                         addargs(&alist, "%s", argv[i]);
                         addargs(&alist, "%s", argv[argc-1]);
                         if (do_local_cmd(&alist))
                                 ++errs;
                         continue;
                 }

Hence:

scp <local1> <local2> should behave identically to cp <local1> <local2>
scp -p <local1> <local2> should behave identically to cp -p <local1> 
<local2>

which I think satisfies POLS.

Regarding xattrs, are you saying that scp <local> <remote> preserves 
xattrs but scp <local> <local> does not?  That would be an inconsistency 
if it were the case, but I've never needed to test this, and I don't see 
any instance of "xattr" in the openssh-portable source.