You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Curd Reinert (Jira)" <ji...@apache.org> on 2021/03/02 12:41:00 UTC
[jira] [Updated] (SSHD-1137) IOException for unsupported
NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Curd Reinert updated SSHD-1137:
-------------------------------
Description:
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.
was:
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.
> 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
> Priority: Major
>
> 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-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org