Why does scp's strict filename checking reject quoted last component but not others?
Clash Royale CLAN TAG#URR8PPP
When I try to scp a file with a slash in its path, the path is quoted for the local host, and the last path component is additionally quoted for the remote host, like scp host:"a/b/'c'" ., it fails with
protocol error: filename does not match request
unless I use the -T option. However, if any other path component is quoted, like scp host:"a/'b'/c" ., it works. Also, if the path is not quoted for the local host, like scp host:a/b/'c' ., it works.
The man page documents -T as:
Disable strict filename checking. By default when copying files from a remote host to a local directory scp checks that the received filenames match those requested on the command-line to prevent the remote end from sending unexpected or unwanted files. Because of differences in how various operating systems and shells interpret filename wildcards, these checks may cause wanted files to be rejected. This option disables these checks at the expense of fully trusting that the server will not send unexpected filenames.
I don't understand how this description explains the behavior I see. What is the rationale for scp's behavior? And is there any way to disable this "feature"?
I am running Ubuntu 16.04 and the remote host is running Ubuntu 12.04.
quoting filenames scp
asked Feb 11 at 14:55
Solomonoff's SecretSolomonoff's Secret
1484
|
show 4 more comments
When I try to scp a file with a slash in its path, the path is quoted for the local host, and the last path component is additionally quoted for the remote host, like scp host:"a/b/'c'" ., it fails with
protocol error: filename does not match request
unless I use the -T option. However, if any other path component is quoted, like scp host:"a/'b'/c" ., it works. Also, if the path is not quoted for the local host, like scp host:a/b/'c' ., it works.
The man page documents -T as:
Disable strict filename checking. By default when copying files from a remote host to a local directory scp checks that the received filenames match those requested on the command-line to prevent the remote end from sending unexpected or unwanted files. Because of differences in how various operating systems and shells interpret filename wildcards, these checks may cause wanted files to be rejected. This option disables these checks at the expense of fully trusting that the server will not send unexpected filenames.
I don't understand how this description explains the behavior I see. What is the rationale for scp's behavior? And is there any way to disable this "feature"?
I am running Ubuntu 16.04 and the remote host is running Ubuntu 12.04.
quoting filenames scp
asked Feb 11 at 14:55
Solomonoff's SecretSolomonoff's Secret
1484
Maybe the remote system removes the quotes and actually sends a filea/b/cwhich will be copied to./con your local system. A filecdoes not match your pattern"'c'". You disable the check with option-T. If you quote the directory'b'you will get a file namedcirrespectively how the remote system interpretsa/'b'. As the transferred file matches the specified pattern you don't need-T.
– Bodo
Feb 11 at 15:13
@Bodo That is a plausible explanation. Perhaps scp doesn't know what shell the remote host uses so it isn't sure that it can canonicalize'c'toc. But it is terribly inconvenient.
– Solomonoff's Secret
Feb 11 at 16:08
What do you expect to be copied byscp host:"a/b/'c'" .? A filec? A file'c'with single quotes in its name?
– Bodo
Feb 11 at 16:13
@Bodo I expecta/b/'c'to pass to the remote shell and the remote shell to interpret it as filecin foldera/b. In other words, the file names stored in the filesystems on the remote and local hosts would both bec. So ideally there would be no error without-T. And the localscpknows that it specified'c'and got backc. But it might not know that the two are the same in the respective filesystems.
– Solomonoff's Secret
Feb 11 at 16:14
Why do you have the nested quotes? If you executecp "a/b/'c'" .thecpcommand would try to copy a file'c'because the inner single quotes are quoted by the outer double quotes. Your expectation howscpshould interpret your strange file name might be confusing for others (for the authors ofscp).
– Bodo
Feb 11 at 16:24
|
show 4 more comments
When I try to scp a file with a slash in its path, the path is quoted for the local host, and the last path component is additionally quoted for the remote host, like scp host:"a/b/'c'" ., it fails with
protocol error: filename does not match request
unless I use the -T option. However, if any other path component is quoted, like scp host:"a/'b'/c" ., it works. Also, if the path is not quoted for the local host, like scp host:a/b/'c' ., it works.
The man page documents -T as:
Disable strict filename checking. By default when copying files from a remote host to a local directory scp checks that the received filenames match those requested on the command-line to prevent the remote end from sending unexpected or unwanted files. Because of differences in how various operating systems and shells interpret filename wildcards, these checks may cause wanted files to be rejected. This option disables these checks at the expense of fully trusting that the server will not send unexpected filenames.
I don't understand how this description explains the behavior I see. What is the rationale for scp's behavior? And is there any way to disable this "feature"?
I am running Ubuntu 16.04 and the remote host is running Ubuntu 12.04.
quoting filenames scp
asked Feb 11 at 14:55
Solomonoff's SecretSolomonoff's Secret
1484
When I try to scp a file with a slash in its path, the path is quoted for the local host, and the last path component is additionally quoted for the remote host, like scp host:"a/b/'c'" ., it fails with
protocol error: filename does not match request
unless I use the -T option. However, if any other path component is quoted, like scp host:"a/'b'/c" ., it works. Also, if the path is not quoted for the local host, like scp host:a/b/'c' ., it works.
The man page documents -T as:
Disable strict filename checking. By default when copying files from a remote host to a local directory scp checks that the received filenames match those requested on the command-line to prevent the remote end from sending unexpected or unwanted files. Because of differences in how various operating systems and shells interpret filename wildcards, these checks may cause wanted files to be rejected. This option disables these checks at the expense of fully trusting that the server will not send unexpected filenames.
I don't understand how this description explains the behavior I see. What is the rationale for scp's behavior? And is there any way to disable this "feature"?
I am running Ubuntu 16.04 and the remote host is running Ubuntu 12.04.
quoting filenames scp
quoting filenames scp
asked Feb 11 at 14:55
Solomonoff's SecretSolomonoff's Secret
1484
asked Feb 11 at 14:55
Solomonoff's SecretSolomonoff's Secret
1484
edited Feb 12 at 12:30
Solomonoff's Secret
asked Feb 11 at 14:55
Solomonoff's SecretSolomonoff's Secret
1484
asked Feb 11 at 14:55
Solomonoff's SecretSolomonoff's Secret
1484
asked Feb 11 at 14:55
Solomonoff's SecretSolomonoff's Secret
1484
1484
Maybe the remote system removes the quotes and actually sends a filea/b/cwhich will be copied to./con your local system. A filecdoes not match your pattern"'c'". You disable the check with option-T. If you quote the directory'b'you will get a file namedcirrespectively how the remote system interpretsa/'b'. As the transferred file matches the specified pattern you don't need-T.
– Bodo
Feb 11 at 15:13
@Bodo That is a plausible explanation. Perhaps scp doesn't know what shell the remote host uses so it isn't sure that it can canonicalize'c'toc. But it is terribly inconvenient.
– Solomonoff's Secret
Feb 11 at 16:08
What do you expect to be copied byscp host:"a/b/'c'" .? A filec? A file'c'with single quotes in its name?
– Bodo
Feb 11 at 16:13
@Bodo I expecta/b/'c'to pass to the remote shell and the remote shell to interpret it as filecin foldera/b. In other words, the file names stored in the filesystems on the remote and local hosts would both bec. So ideally there would be no error without-T. And the localscpknows that it specified'c'and got backc. But it might not know that the two are the same in the respective filesystems.
– Solomonoff's Secret
Feb 11 at 16:14
Why do you have the nested quotes? If you executecp "a/b/'c'" .thecpcommand would try to copy a file'c'because the inner single quotes are quoted by the outer double quotes. Your expectation howscpshould interpret your strange file name might be confusing for others (for the authors ofscp).
– Bodo
Feb 11 at 16:24
|
show 4 more comments
Maybe the remote system removes the quotes and actually sends a filea/b/cwhich will be copied to./con your local system. A filecdoes not match your pattern"'c'". You disable the check with option-T. If you quote the directory'b'you will get a file namedcirrespectively how the remote system interpretsa/'b'. As the transferred file matches the specified pattern you don't need-T.
– Bodo
Feb 11 at 15:13
@Bodo That is a plausible explanation. Perhaps scp doesn't know what shell the remote host uses so it isn't sure that it can canonicalize'c'toc. But it is terribly inconvenient.
– Solomonoff's Secret
Feb 11 at 16:08
What do you expect to be copied byscp host:"a/b/'c'" .? A filec? A file'c'with single quotes in its name?
– Bodo
Feb 11 at 16:13
@Bodo I expecta/b/'c'to pass to the remote shell and the remote shell to interpret it as filecin foldera/b. In other words, the file names stored in the filesystems on the remote and local hosts would both bec. So ideally there would be no error without-T. And the localscpknows that it specified'c'and got backc. But it might not know that the two are the same in the respective filesystems.
– Solomonoff's Secret
Feb 11 at 16:14
Why do you have the nested quotes? If you executecp "a/b/'c'" .thecpcommand would try to copy a file'c'because the inner single quotes are quoted by the outer double quotes. Your expectation howscpshould interpret your strange file name might be confusing for others (for the authors ofscp).
– Bodo
Feb 11 at 16:24
Maybe the remote system removes the quotes and actually sends a file
a/b/c which will be copied to ./c on your local system. A file c does not match your pattern "'c'". You disable the check with option -T. If you quote the directory 'b' you will get a file named c irrespectively how the remote system interprets a/'b'. As the transferred file matches the specified pattern you don't need -T.– Bodo
Feb 11 at 15:13
Maybe the remote system removes the quotes and actually sends a file
a/b/c which will be copied to ./c on your local system. A file c does not match your pattern "'c'". You disable the check with option -T. If you quote the directory 'b' you will get a file named c irrespectively how the remote system interprets a/'b'. As the transferred file matches the specified pattern you don't need -T.– Bodo
Feb 11 at 15:13
@Bodo That is a plausible explanation. Perhaps scp doesn't know what shell the remote host uses so it isn't sure that it can canonicalize
'c' to c. But it is terribly inconvenient.– Solomonoff's Secret
Feb 11 at 16:08
@Bodo That is a plausible explanation. Perhaps scp doesn't know what shell the remote host uses so it isn't sure that it can canonicalize
'c' to c. But it is terribly inconvenient.– Solomonoff's Secret
Feb 11 at 16:08
What do you expect to be copied by
scp host:"a/b/'c'" .? A file c? A file 'c' with single quotes in its name?– Bodo
Feb 11 at 16:13
What do you expect to be copied by
scp host:"a/b/'c'" .? A file c? A file 'c' with single quotes in its name?– Bodo
Feb 11 at 16:13
@Bodo I expect
a/b/'c' to pass to the remote shell and the remote shell to interpret it as file c in folder a/b. In other words, the file names stored in the filesystems on the remote and local hosts would both be c. So ideally there would be no error without -T. And the local scp knows that it specified 'c' and got back c. But it might not know that the two are the same in the respective filesystems.– Solomonoff's Secret
Feb 11 at 16:14
@Bodo I expect
a/b/'c' to pass to the remote shell and the remote shell to interpret it as file c in folder a/b. In other words, the file names stored in the filesystems on the remote and local hosts would both be c. So ideally there would be no error without -T. And the local scp knows that it specified 'c' and got back c. But it might not know that the two are the same in the respective filesystems.– Solomonoff's Secret
Feb 11 at 16:14
Why do you have the nested quotes? If you execute
cp "a/b/'c'" . the cp command would try to copy a file 'c' because the inner single quotes are quoted by the outer double quotes. Your expectation how scp should interpret your strange file name might be confusing for others (for the authors of scp).– Bodo
Feb 11 at 16:24
Why do you have the nested quotes? If you execute
cp "a/b/'c'" . the cp command would try to copy a file 'c' because the inner single quotes are quoted by the outer double quotes. Your expectation how scp should interpret your strange file name might be confusing for others (for the authors of scp).– Bodo
Feb 11 at 16:24
|
show 4 more comments
1 Answer
1
active
oldest
votes
Ubuntu people are known for pushing through inconsiderate/partial patches (recent example); in your case, it's about this patch, which is less than 3 weeks old, including the time spent in snapshots:
check in scp client that filenames sent during remote->local directory
copies satisfy the wildcard specified by the user.
This checking provides some protection against a malicious server
sending unexpected filenames, but it comes at a risk of rejecting wanted
files due to differences between client and server wildcard expansion rules.
For this reason, this also adds a new -T flag to disable the check.
reported by Harry Sintonen
fix approach suggested by markus@;
has been in snaps for ~1wk courtesy deraadt@
OpenBSD-Commit-ID: 00f44b50d2be8e321973f3c6d014260f8f7a8eda
That is not ready for prime time (it's naively using fnmatch(3) on the basename of the file) and already had to fixed to allow for brace expansions.
Conclusion: it's a bug; it'll probably be fixed sooner or later; or if not, be prepared to always disable this new misfeature with -T.
answered Feb 12 at 5:27
Uncle BillyUncle Billy
6496
Apologies, I'm new on this site and didn't know scp would behave differently on Ubuntu than on other distros.
– Solomonoff's Secret
Feb 12 at 12:29
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499958%2fwhy-does-scps-strict-filename-checking-reject-quoted-last-component-but-not-oth%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Ubuntu people are known for pushing through inconsiderate/partial patches (recent example); in your case, it's about this patch, which is less than 3 weeks old, including the time spent in snapshots:
check in scp client that filenames sent during remote->local directory
copies satisfy the wildcard specified by the user.
This checking provides some protection against a malicious server
sending unexpected filenames, but it comes at a risk of rejecting wanted
files due to differences between client and server wildcard expansion rules.
For this reason, this also adds a new -T flag to disable the check.
reported by Harry Sintonen
fix approach suggested by markus@;
has been in snaps for ~1wk courtesy deraadt@
OpenBSD-Commit-ID: 00f44b50d2be8e321973f3c6d014260f8f7a8eda
That is not ready for prime time (it's naively using fnmatch(3) on the basename of the file) and already had to fixed to allow for brace expansions.
Conclusion: it's a bug; it'll probably be fixed sooner or later; or if not, be prepared to always disable this new misfeature with -T.
answered Feb 12 at 5:27
Uncle BillyUncle Billy
6496
Apologies, I'm new on this site and didn't know scp would behave differently on Ubuntu than on other distros.
– Solomonoff's Secret
Feb 12 at 12:29
add a comment |
Ubuntu people are known for pushing through inconsiderate/partial patches (recent example); in your case, it's about this patch, which is less than 3 weeks old, including the time spent in snapshots:
check in scp client that filenames sent during remote->local directory
copies satisfy the wildcard specified by the user.
This checking provides some protection against a malicious server
sending unexpected filenames, but it comes at a risk of rejecting wanted
files due to differences between client and server wildcard expansion rules.
For this reason, this also adds a new -T flag to disable the check.
reported by Harry Sintonen
fix approach suggested by markus@;
has been in snaps for ~1wk courtesy deraadt@
OpenBSD-Commit-ID: 00f44b50d2be8e321973f3c6d014260f8f7a8eda
That is not ready for prime time (it's naively using fnmatch(3) on the basename of the file) and already had to fixed to allow for brace expansions.
Conclusion: it's a bug; it'll probably be fixed sooner or later; or if not, be prepared to always disable this new misfeature with -T.
answered Feb 12 at 5:27
Uncle BillyUncle Billy
6496
Apologies, I'm new on this site and didn't know scp would behave differently on Ubuntu than on other distros.
– Solomonoff's Secret
Feb 12 at 12:29
add a comment |
Ubuntu people are known for pushing through inconsiderate/partial patches (recent example); in your case, it's about this patch, which is less than 3 weeks old, including the time spent in snapshots:
check in scp client that filenames sent during remote->local directory
copies satisfy the wildcard specified by the user.
This checking provides some protection against a malicious server
sending unexpected filenames, but it comes at a risk of rejecting wanted
files due to differences between client and server wildcard expansion rules.
For this reason, this also adds a new -T flag to disable the check.
reported by Harry Sintonen
fix approach suggested by markus@;
has been in snaps for ~1wk courtesy deraadt@
OpenBSD-Commit-ID: 00f44b50d2be8e321973f3c6d014260f8f7a8eda
That is not ready for prime time (it's naively using fnmatch(3) on the basename of the file) and already had to fixed to allow for brace expansions.
Conclusion: it's a bug; it'll probably be fixed sooner or later; or if not, be prepared to always disable this new misfeature with -T.
answered Feb 12 at 5:27
Uncle BillyUncle Billy
6496
Ubuntu people are known for pushing through inconsiderate/partial patches (recent example); in your case, it's about this patch, which is less than 3 weeks old, including the time spent in snapshots:
check in scp client that filenames sent during remote->local directory
copies satisfy the wildcard specified by the user.
This checking provides some protection against a malicious server
sending unexpected filenames, but it comes at a risk of rejecting wanted
files due to differences between client and server wildcard expansion rules.
For this reason, this also adds a new -T flag to disable the check.
reported by Harry Sintonen
fix approach suggested by markus@;
has been in snaps for ~1wk courtesy deraadt@
OpenBSD-Commit-ID: 00f44b50d2be8e321973f3c6d014260f8f7a8eda
That is not ready for prime time (it's naively using fnmatch(3) on the basename of the file) and already had to fixed to allow for brace expansions.
Conclusion: it's a bug; it'll probably be fixed sooner or later; or if not, be prepared to always disable this new misfeature with -T.
answered Feb 12 at 5:27
Uncle BillyUncle Billy
6496
edited Feb 12 at 14:17
answered Feb 12 at 5:27
Uncle BillyUncle Billy
6496
answered Feb 12 at 5:27
Uncle BillyUncle Billy
6496
answered Feb 12 at 5:27
Uncle BillyUncle Billy
6496
6496
Apologies, I'm new on this site and didn't know scp would behave differently on Ubuntu than on other distros.
– Solomonoff's Secret
Feb 12 at 12:29
add a comment |
Apologies, I'm new on this site and didn't know scp would behave differently on Ubuntu than on other distros.
– Solomonoff's Secret
Feb 12 at 12:29
Apologies, I'm new on this site and didn't know scp would behave differently on Ubuntu than on other distros.
– Solomonoff's Secret
Feb 12 at 12:29
Apologies, I'm new on this site and didn't know scp would behave differently on Ubuntu than on other distros.
– Solomonoff's Secret
Feb 12 at 12:29
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499958%2fwhy-does-scps-strict-filename-checking-reject-quoted-last-component-but-not-oth%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Maybe the remote system removes the quotes and actually sends a file
a/b/cwhich will be copied to./con your local system. A filecdoes not match your pattern"'c'". You disable the check with option-T. If you quote the directory'b'you will get a file namedcirrespectively how the remote system interpretsa/'b'. As the transferred file matches the specified pattern you don't need-T.– Bodo
Feb 11 at 15:13
@Bodo That is a plausible explanation. Perhaps scp doesn't know what shell the remote host uses so it isn't sure that it can canonicalize
'c'toc. But it is terribly inconvenient.– Solomonoff's Secret
Feb 11 at 16:08
What do you expect to be copied by
scp host:"a/b/'c'" .? A filec? A file'c'with single quotes in its name?– Bodo
Feb 11 at 16:13
@Bodo I expect
a/b/'c'to pass to the remote shell and the remote shell to interpret it as filecin foldera/b. In other words, the file names stored in the filesystems on the remote and local hosts would both bec. So ideally there would be no error without-T. And the localscpknows that it specified'c'and got backc. But it might not know that the two are the same in the respective filesystems.– Solomonoff's Secret
Feb 11 at 16:14
Why do you have the nested quotes? If you execute
cp "a/b/'c'" .thecpcommand would try to copy a file'c'because the inner single quotes are quoted by the outer double quotes. Your expectation howscpshould interpret your strange file name might be confusing for others (for the authors ofscp).– Bodo
Feb 11 at 16:24