0

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?

Chicago9
  • 1
  • 1
    Does the latest git version of phpseclib work for you? In particular, I'm wondering if https://github.com/phpseclib/phpseclib/commit/f189b9aae24b8ecf11fdfb7a1446ff759dd30bb4 might fix the issue for you. – neubert Jul 28 '22 at 10:19
  • Martin, yes $sftp->realpath("/ARTDONE.G9876TT1") returns "/ARTDONE.G9876TT1", stripping the first leading slash and then chdir returns false. – Chicago9 Jul 28 '22 at 19:47
  • The commit mentioned by neubert above might well do the trick, but it is not in the latest production version 3.014. It even refers to double forward slashes in the comments. My main concern is that I need a production ready solution within a few weeks. And Martin's script solution in his WinScp looks very inviting. – Chicago9 Jul 28 '22 at 19:56
  • So the mainframe service provider forwarded me to their sftp software provider's manual, Co:Z SFTP - User's Guide, at http://dovetail.com/docs/sftp/sftpdoc.pdf where it was recommended that I try /-/ instead of // and that solved the problem. This usage of // is the mainframe's way of navigating to a partitioned dataset rather than a directory. PHPSECLIB V3 does not automatically deal with this issue. Kudos to Martin whose software does. – Chicago9 Jul 28 '22 at 20:52
  • I've posted what I believe explains the behaviour you are seeing. If you have an alternative solution, please post it as an alternative answer. – Martin Prikryl Jul 29 '22 at 05:43
  • If you post on the GitHub issue tracker for phpseclib it's author might be willing to do a release within a few days of your asking to have one done. He's done it before. – neubert Jul 29 '22 at 16:04

2 Answers2

0

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.

Martin Prikryl
  • 188,800
  • 56
  • 490
  • 992
  • Using absolute paths works as long as I use /-/ instead of // . The sftp server I expect sees this and changes it to // . There is an empty inaccessible file called .zos_catalog which might be the clue for PHPSECLIB to accept the leading // as valid instead of converting it to a single leading / which fails at the server level. – Chicago9 Aug 03 '22 at 17:21
0

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.

phunsoft
  • 2,674
  • 1
  • 11
  • 22