unzip v5.52 problem in batch

[Dr. Ian Robinson]

I have written a dcl procedure to test whether
zip file attachments to email messages are
password protected or not. This is to be used
in the PMDF CONVERSION channel as part of our
Sophos virus scanning. The test procedure
works fine interactively and in batch from
both unprivileged and fully privileged accounts
on an old Alpha 8200 running OpenVMS V7.1-2.

It also works fine interactively and in batch
from an unprivileged account on an ES80
running OpenVMS V7.3-2. However, in batch
mode from a privileged account on this ES80
the batch job hangs when it reaches the line

$ unzip/test/quiet zip-test.zip

and the zip file is a password protected
file created with zipcloak.

A simplified version of the procedure is :

$ unzip :== $GEN_1:[IAN]UNZ552XV-AXP.EXE
$ zip_file_name = "''p1'"
$ on error then continue
$ unzip/test/quiet 'zip_file_name'
$ exit_status = $status

The log file from a test batch job on the
system running V7.1-2 is :

$ unzip :== $GEN_1:[IAN]UNZ552XV-AXP.EXE
$ zip_file_name = "ZIP-TEST.ZIP"
$ on error then continue
$ unzip/test/quiet ZIP-TEST.ZIP
skipping: zip_test/funny_characters unable to get password
skipping: zip_test/punch.jpg unable to get password
skipping: zip_test/text file.txt unable to get password
At least one error was detected in D_R:[ROBBO]ZIP-TEST.ZIP;1
$ exit_status = $status

On the ES80 the log file looks like :

$ unzip :== $GEN_1:[IAN]UNZ552XV-AXP.EXE
$ zip_file_name = "ZIP-TEST.ZIP"
$ on error then continue
$ unzip/test/quiet ZIP-TEST.ZIP
[GEN_1:[IAN]ZIP-TEST.ZIP;1] zip_test/funny_characters password:
%JBC-F-JOBABORT, job aborted during execution

The abort is a result of me deleting the entry from the batch queue after it sat there for some time.

I have compared the privs of the privileged
accounts on the two machines and there doesn't
appear to be any difference. Nor are there any
differences with the various quotas.

Does anyone have any suggestions as to why this might be happening?

Thanks in advance.

[Hoff · Accepted solution]

This is easily the best problem report posted in this ITRC forum in quite some time. Good and complete configuration and environment details have been included on the post; thank you for that.

I've not tried embedding the password with DCL with zip, but I've seen cases where a privileged user password prompt can end up over on the console.

I'm using the Unix-like switches here, and not the DCL-like qualifier.

Here, try a test with unzip -v or -vv and see if you get any diagnostics that point to a difference.

When the process hangs, use another privileged process and ANALYZE /SYSTEM and SHOW PROCESS /INDEX=pid to see what channels the process has open, and where they go.

If you know the password and you're willing to embed it, then use

unzip "-P password"

Either SET PROCESS /PARSE=EXTENDED or quoting for uppercase switches is required here.

Unzip /test/quiet is unzip -tq or -tqq or -t -qq

zip 6.0 and unzip 3.0 are current. If you're working with zip files past 2 GB or so, then you will need to upgrade to 6.0 and 3.0.

(Assuming Mr Schweda doesn't instantiate with a specific diagnosis, you may end up building unzip from source and seeing what happens here with the Debugger.)

[Steven Schweda]

> This is easily the best problem report [...]

But where's the fun in that?

I ran a quick test here using UnZip 5.52 and
6.0, using my personal account and SYSTEM,
and all I get are the "skipping: xxx
unable to get password" messages, which is
what I'd expect when it considers asking the
user for the password, and there's no one to
ask. So far as I can tell from a quick
inspection, it reads from stdin (SYS$INPUT),
so unless someone has redefined that, I can't
immediately explain any other behavior.

[Jim_McKinney]

fwiw, long ago with (a much) older version of UNZIP (and ZIP) I had to embed the UNZIP within a pseudo-terminal application in order to handle passwords and encryption - UNZIP (at least that long ago vintage) demanded a terminal.

[Steven Schweda]

> [...] I had to embed the UNZIP within a
> pseudo-terminal [...]

The "-P" option has existed for a while, but
it was left undocumented (outside of the
source code) because it was considered such a
bad idea to use it. In recent years, we got
tired of answering questions about it, so
it's now in the "-hh" help on UnZip.

> [...] it reads from stdin (SYS$INPUT) [...]

Or SYS$COMMAND, or SYS$something-or-other.

[Steven Schweda]

If you're still chasing this one, you might
toss in some simple diagnostics to reveal
what it might be trying to read when it
hangs:

$ show logical sys$command
$ show logical sys$input
$ unzip [...]

[Dr. Ian Robinson]

Sorry for the delay in responding to your suggestions - I have
had other pressing issues.

Anyway, thanks to all who have taken the time and effort to offer
suggestions.

I had already included things like :

$ show logical sys$input
$ show logical sys$command

in the batch jobs because I was wondering whether somehow these had been re-defined and the procedure was trying to read the
password from somewhere weird. But they had not.

The suggestion to submit the batch job and when the process hangs to use another privileged process to ANALYZE/SYSTEM and
SHOW PROCESS/INDEX=pid/CHANNEL was a very good starting point. It showed that for some reason the process had a file called
DSA10:[IAN].;1 open :

Process index: 0060 Name: BATCH_1752 Extended PID: 2C862860
--------------------------------------------------------------------


Process active channels
-----------------------

Channel CCB Window Status Device/file accessed
------- --- ------ ------ --------------------
0010 7FF7A000 00000000 DSA10:
0020 7FF7A020 82261800 DSA10:[IAN]UNZ552XV-AXP.EXE;1
0030 7FF7A040 8234FF40 $2$DKA0:[SYSCOMMON.SYSLIB]LIBOTS.EXE;1 (
section file)
0040 7FF7A060 8234FB40 $2$DKA0:[SYSCOMMON.SYSLIB]LIBRTL.EXE;1 (
section file)
0050 7FF7A080 8235D980 $2$DKA0:[SYSCOMMON.SYSEXE]DCL.EXE;1 (sec
tion file)
0060 7FF7A0A0 8234FAC0 $2$DKA0:[SYSCOMMON.SYSLIB]DCLTABLES.EXE;
403 (section file)
0070 7FF7A0C0 823A5800 DSA10:[IAN]TU.LOG;6
0080 7FF7A0E0 824867C0 DSA10:[IAN]TU.COM;5
0090 7FF7A100 82354200 $2$DKA0:[SYSCOMMON.SYSLIB]DECC$SHR_EV56.
EXE;1 (section file)
00A0 7FF7A120 82353C00 $2$DKA0:[SYSCOMMON.SYSLIB]DPML$SHR.EXE;1
(section file)
00B0 7FF7A140 82352180 $2$DKA0:[SYSCOMMON.SYSLIB]CMA$TIS_SHR.EX
E;1 (section file)
00C0 7FF7A160 823A7B40 DSA10:[IAN]ZIP-TEST.ZIP;1
00D0 7FF7A180 8222BD80 DSA10:[IAN].;1
00E0 7FF7A1A0 00000000 DSA10:

Total number of open channels : 14.
SDA>


It turns out that this file already existed and was, in fact, an empty file which had a creation date of some months ago - a carry
over from some other issue no doubt (can't remember what).

So, when I deleted this file and re-submitted the batch job it all
worked fine.

Since sys$input is defined to be _DSA10: in this batch job (default) is it possible that this is a bug and that sys$input is being
interpreted as _DSA10:[IAN].;1 ?

I never quite understood how the default definition of sys$input in batch translated to the actual command procedure which was
submitted - but clearly it is as the log file for the following simple test procedure shows :

$ show logical sys$input
$ show logical sys$command
$ show logical sys$output
$ read sys$input line
thisisatest
$ show symbol line
$ exit

$ show logical sys$input
"SYS$INPUT" = "_DSA10:" (LNM$PROCESS_TABLE)
$ show logical sys$command
"SYS$COMMAND" = "_DSA10:" (LNM$PROCESS_TABLE)
$ show logical sys$output
"SYS$OUTPUT" = "_DSA10:" (LNM$PROCESS_TABLE)
$ read sys$input line
$ show symbol line
LINE = "thisisatest"
$ exit

Other tests show that if the .;1 file is not empty the batch job completes and the log file contains entries such as :

$ unzip/test/quiet ZIP-TEST.ZIP
[GEN_1:[IAN]ZIP-TEST.ZIP;1] zip_test/funny_charactors password:
password incorrect--reenter:
password incorrect--reenter:
[GEN_1:[IAN]ZIP-TEST.ZIP;1] zip_test/punch.jpg password:
password incorrect--reenter:
password incorrect--reenter:
[GEN_1:[IAN]ZIP-TEST.ZIP;1] zip_test/text file.txt password:
password incorrect--reenter:
password incorrect--reenter:
Caution: zero files tested in GEN_1:[IAN]UOM-ZIP-TEST.ZIP;1.
3 files skipped because of incorrect password.
$ exit_status = $status

so I guess unzip must be trying to read the password from the file DSA10:[IAN].;1.

If I create a password protected zip file for which I know the password and put this password in the file DSA10:[IAN].;1 then
the log shows :

$ unzip/test/quiet ZIP-TEST.ZIP
[GEN_1:[IAN]ZIP-TEST.ZIP;2] test2/ password:

No errors detected in compressed data of GEN_1:[IAN]UOM-ZIP-TEST.ZIP;2.

Anyway, as a workaround I guess I need to either specifically define sys$input or perhaps add a :

$ delete .;1

to my procedure before the unzip.