[
https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315003#comment-17315003
]
Curd Reinert commented on SSHD-1137:
------------------------------------
Hi [~lgoldstein], I wanted to give you an update. I will try to test the fix -
actually started today, but initially had some trouble with reproducing the
problem in the first place - it seems that NOFOLLOW_LINKS _is_ supported by (at
least some of the) JVMs from AdoptOpenJDK for AIX, so I needed to find a IBM
JVM to reproduce it.
Nevertheless, I will see what I can do in testing the fix. As our application
is build on version 2.4, I'm not too sure how far I will get. I'll let you know.
> IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH
> SFTP client
> -----------------------------------------------------------------------------------------
>
> Key: SSHD-1137
> URL: https://issues.apache.org/jira/browse/SSHD-1137
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.5.1
> Environment: SFTP-Server running on AIX
> OpenSSH SFTP client
> Reporter: Curd Reinert
> Assignee: Lyor Goldstein
> Priority: Minor
> Labels: AIX, aix
> Fix For: 2.7.0
>
>
> When accessing an SFTP server running on AIX with an OpenSSH SFTP client
> (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well),
> I get the following exception:
> [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class:
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method:
> handleSetFileAttributeFailure Line: 2645 -
> /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread
> =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001,
> pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv]
> posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure
> details
> java.io.IOException: NOFOLLOW_LINKS is not supported on this platform
> at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793)
> at
> sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242)
> at
> sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272)
>
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541)
> at
> org.apache.sshd.server.subsystem.sftp.FileHandle.<init>(FileHandle.java:77)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344)
> at
> de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> I've had a look into the source code. It seems the permissions requested by
> the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not
> supported by the file systems. This fails equally on Windows, Linux or AIX
> for an initial open, and therefore the catch block in [FileHandle (line
> 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75]
> is reached. Here the openFile for the channel is repeated without file
> attributes - succesfully - and then an attempt is made to set the file
> attributes with subsystem.doSetAttributes(file, attrs, false) - but this call
> needs that third argument for the follow link option, and setting it to false
> leads to using the "NOFOLLOW_LINK" option, and that is not supported on AIX,
> which finally causes the opening to fail.
> My assumption is that when setting the file attributes, the caller assumed
> that "false" is a good choice as a default for a case when there is no
> indication if links should be followed or not. But I would say the reverse is
> true, and "true" should be used in this case, as it probably is if the
> original open does not fail.
> Changing "false" into "true" in FileHandle, line 77, should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
