mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiri vanek (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SSHD-787) Secure trasnfer file's directoy existence is alway checked (on real FS) no metter of any other settings
Date Thu, 21 Dec 2017 18:04:00 GMT

    [ https://issues.apache.org/jira/browse/SSHD-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16300376#comment-16300376

jiri vanek commented on SSHD-787:

Yes, I'm using clone and built about 60 minutes old of apache/mina-sshd.
And Yes, I can be doing something wrong....
I'm calling:
 scp -r  -P 9822     tester@localhost:magicBean/logs/ /tmp/ 
and I get    CWD/magicBean/logs: unknown file type

Which can be found on three places in ScpHelper.  all see sm to be somehow redundant n new
However, I have nothing well suitbael to give to those methods. As those call I forward to
remote network resolver.

If you cant accommodate, then so be it. You made amazing job for me to be able to download
and uplaod via absolutely non-fs paths.  Recursive upload now works for me (it was my error
as you probably guessed) and recursive downlaod may not gave sense.

However, if you check the three occurences of "unknown file type" in ScpHelper, would be appreciated,

I know, taht newly overrideable  resolveOutgoingFilePath is called here.  But here I really
have nothing to gave to it.  If I'm about to do something, I can do it about it inside sendDir,
but that method already works wit protocol, so it it is saying me, step back, and redesing
approach above it. But that is something more close to "not accommodate-abele". But you can
be sure that if somebody wills tart to use thsi new feature, he will swim into this.

When I provide some fake hook into  the protected void send(Path local ... then  Ihen the
openRead of scpOpener do its job later

> Secure trasnfer file's directoy existence is alway checked (on real FS) no metter of
any other settings
> -------------------------------------------------------------------------------------------------------
>                 Key: SSHD-787
>                 URL: https://issues.apache.org/jira/browse/SSHD-787
>             Project: MINA SSHD
>          Issue Type: New Feature
>            Reporter: jiri vanek
>            Assignee: Goldstein Lyor
>            Priority: Minor
>             Fix For: 1.7.0
> Hello!
> mina-sshd iss awesomely configurable tool.  It is so powerful, that  it allows  programmer
to provide VirtualFileSystem or even more, ScpFileOpener for custom stream.
> However, before any of above comes to play,  the target path is checked by simple nio.File.exists,
which successfully kills any afterwards customisations
> This is caused by following chain:
> receiveFile is called first, and alwys calls LocalFileScpTargetStreamResolver
> https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/common/scp/ScpHelper.java#L334
> This is imo the core of bug - the StreamResolver should be replaceable. Or at least it
should take in consideration VirtualFileSystem and/or ScpFileOpener, ending like https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/common/scp/helpers/LocalFileScpTargetStreamResolver.java#L91
 or any of  many checks *before* there is actual call to custom StreamOpener. Those checks
consist from simple path,parene, path.isDirecotry path.isWriteable and simialr.   IMho nothing
of this should happen when custom ScpFileOpener is in play. But more likely I'm underestimating
some security check.
> I will be happy to implement those fix if we agree on approach.
> Currnetly I have in mind possiblity of custom ScpTargetStreamResolver set in simialr
way as StramOpener is, or fixing LocalFileScpTargetStreamResolver so it do nto check if custom
StramOpener is in play.
> Background
> I'm usign mina as moreover simple scp-l;ike upload.  Now the system where it runs changed
dramatically, so - based on the target path - I need to store the file on completely different
place ("backward comaptible upload:) ) or - in addition - to send it over network .
> Due to changes of destinations, I was unsuccessful to use VirtualFileSystem and in case
of network forwarding I think I'm domed to StreamOpener anyway.
> Best regards
>   j.

This message was sent by Atlassian JIRA

View raw message