The phpseclib $sftp->chdir('//ARTDONE.G9876TT1') fails on z/OS sftp server. The windows psftp command line of "CD //ARTDONE.G9876TT1" works

Question

I get a valid connection with phpseclib but because of the server's requirements I must issue a change remote directory command, $sftp->chdir($dir="//ARTDONE.G9876TT1"), to this directory, (exact format, not the actual name). This change directory command works with Putty's psftp.exe as "CD //ARTDONE.G9876TT1" in windows and with WinSCP's "go to this folder GUI input" but not with PHPSECLIB's sftp object method. Is there something about this directory format that needs to change when using phpseclib? The error message is "permission denied", but I get that same message for any other navigation commands.

Is there a way to issue literal sftp commands with phpseclib sftp?

Or can I use $ssh->exec("CD //ARTDONE.G9876TT1") in some way within the $sftp object that I cannot currently imagine?

Answer 1

The phpseclib appends / to the path in SFTP::chdir call. I believe this is what your server does not like.

Note that SFTP does not even use the concept of a working directory. It's faked locally by phpseclib (and other clients like WinSCP or OpenSSH). So you do not really need to use SFTP::chdir. You might instead use absolute paths in all phpseclib API calls. Alternatively, just setting SFTP::pwd has the same effect as calling SFTP::chdir, except that you will bypass the validation that causes you the troubles.

Answer 2

Accessing z/OS Data Sets via SFTP/FTP

Appending a / surely breaks the access. The OP is accessing an IBM z/OS system running an SFTP server.

IBM z/OS

z/OS is kind a hybrid operating system having a traditional MVS based "kernel" (not really named "kernel" in the doc), and a XPG 4.2 compliant UNIX kernel running in parallel. The UINX side supports file systems with directories and files. The MVS side has a completely different "file system", based on data sets which are named in a non-hierarchal system.

The UNIX file system on z/OS

There is not much to say about the UNIX file system on z/OS. Is it XPG compliant, thus the usage is not different to any other UNIX lik system.

The MVS Data Sets on z/OS

As said above, there is the traditional MVS Data Set based "file system" on z/OS, which is quite different to much you know about files and directories on UNIX system.

Disk Space on z/OS is assigned to MVS data sets. Data sets are named using dot separates names, that can be up to 44 characters long. The parts between two dots can be up to 8 characters long.

Examples:

• ARTDONE.G9876TT1
• ARTDONE.NEXT.DATA.SET
• ARTDONE.NEXT.ANOTHER.ONE
• SYS1.LINKLIB
• ZUSER.SOURCE.REXX

What seems to be a hierarchy in the first three examples, is not. They are unrelated from the physical point of view, though related in a logical.

Note: Slashed / are not valid in MVS data set names.

SFTP/FTP servers on z/OS

SFTP/FPT servers in z/OS mimic the client side view of directories and files when accessing MVS Data Sets in that the dots in the names are kind of treated like slashes in UNIX. I.e. they support pwd and cd based on the dots.

Example: cd //ARTDONE.NEXT sets the current working directory to ARTDONE.NEXT. A ls the lists all data sets, of which the name starts with ARTDONE.NEXT, i.e.

• ARTDONE.NEXT.DATA.SET
• ARTDONE.NEXT.ANOTHER.ONE

but not ARTDONE.G9876TT1.

But how would the server know whether a client side "directory" access is meant to access the UNIX or the MVS data world? The // at the beginning of the parameter passed to the server indicates the server shall switch to the MVS data set world.

Conclusion

client side software should be careful when verifying paths that might be sent to z/OS servers. Accept // as a special indicator. Do not append / in all cases.

More Detailes

There is much more behind this topic than can be described here. Read IBM documentation on z/OS if interested. I would recommend Introduction to the New Mainframe: z/OS Basics as a starter.