For the default Python install, if a user starts a notebook via an ssh session (eg. jupyter-notebook --port=<port#> --ip=<LPAR’s ip>), it sends them a token via their terminal. If a user submits the same command using BPXBATCH however, this token is printed to the batch job’s output (STDERR). This would allow anyone who can read the job’s output on the JES queue to use the token to execute code as the user that submitted the batch job.
How have others stopped users from doing this?
+1For the default Python install, if a user starts a notebook via an ssh session (eg. jupyter-notebook --port=<port#> --ip=<LPAR’s ip>), it sends them a token via their terminal. If a user submits the same command using BPXBATCH however, this token is printed to the batch job’s output (STDERR). This would allow anyone who can read the job’s output on the JES queue to use the token to execute code as the user that submitted the batch job.
How have others stopped users from doing this?
Hello Dan,
In my understanding, one needs to explicitly allocate STDERR to SYSOUT in order for it to be visible in the job output; that is, it must be done deliberately. Please correct me if I’m wrong.
BPXBATCH allows to send stderr and other standard streams to data sets or to USS files, and in such cases RACF and/or USS access permissions can provide the required security. Unfortunately in my experiments, data sets didn’t really work well because the message from Jupyter got buffered and didn’t appear in the data set until I stopped the job. Maybe some of the DD/DCB options could fix that - I just didn’t try. On the good side of it, I was able to successfully open the Jupyter link when STDERR was pointing to a Unix file, which I viewed from ISPF.
Regards,
Vladimir
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
