Curd Reinert created SSHD-1137:
----------------------------------
Summary: 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
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: [email protected]
For additional commands, e-mail: [email protected]
