CGI problem between nodes

[Willem Grooters]

OpenVMS 7.3-2, Apache 2.1-1; two systems, not clustered together.

A CGI procedure will start another procedure under a different UIC, wait for it's output, next types the output to SYS$OUTPUT, deletes the file and exits.

On node1: no problem.
On Node2: The working script is created and contaisn the right protection. However, procedure starts but fails before creating an output file.
The CGI-script has been minimized to the bare function: Setup and execute. This is run interactively (by the requesting user) and succeeds without a problem.

File- and directory protecftions have been checked; logicals as set in CGI-environment seem fine.

Details in attached file.

[Hoff]

Attached file?

[Willem Grooters]

Oops... Anyway.

A collegue (more a system manager than I am) suggested usage of

$ SET AUDIT/ALARM/ENABLE=FILE=FAIL
$ REPLY/ENABLE

to locate the problem. It turned out that the login directory of the remote_user could not be read by APACHE$WWW. Which is weird, since the file contains an ACE that allows the webserver to read the directory ((ID=APACHE$WWW, ACCESS=READ+EXECUTE))

The direcgtory is procected by an ACE for an identifier which has READ+WRITE_EXECUTE access. Granting this identifier to APACHE$WWW (and restarting the server) solved the issue, but should be avoided when possible.

So I added WRITE access to the ACE for APACHE$WWW, (and revoked the identifier); but the directory remained inaccessable: same problem as before, even when the identifier was granted to REMOTE_USER.

[Willem Grooters]

Correction:
The problem must be triggered by the script executed under UIC of REMOTE_USER: the directory that cannot be accessed has nothing to do with the user, but the script accesses files in directories contained within this directory.

[Willem Grooters]

Correction 2:
The procedure to be executed by Loginout.exe resides under this directory, but the wole path - and the file itself, is accessable by APACHE$WWW based on ACE. REMOTE_USER however has no access to the directories, but can read and execute the file. Hoever, granting the required identifier makes no difference for the CGI procedure.

[Robert Atkinson]

Willem, what about using SET WATCH in the Apache startup to see where the privilege problems lies?

Have you checked the directory privileges as well as the file privs?

Rob.

[Jim_McKinney]

I know nothing of APACHE but in your attachment I see

$! { This proceduere is created on appl_subtmp }
$! { It will basically contain the following code }
$! Login into application and subsystem
$!
$! { @CGI_APPL_LOGIN }
$ define/trans=conc appl_progroot dev:[progpath.]
$ define/trans=conc appl_dataroot dev:[datapath.]
$ define appl_database appl_daatroot:[database]db.rdb
$! { @CGI_APPL_SUB }
$ define appl_subcom appl_progroot:[sub.com]
$ define appl_subexe appl_progroot:[sub.exe]
$ define appl_subdb appl_dataroot:[sub.db]
$ define appl_subtmp appl_dataroot:[sub.tmp]
$ define appl_sublog appl_dataroot:[sub.log]
$ define appl_subdatabase applsubdb:dbsub.rdb
$!
$! Output name defined by CGI.COM
$!
$ define sys$output appl_subtmp applsub_tmp:''uniq'.OUT
$!
$! Data passed by Apache to CGI.COM
$!
$ remote_user = "REMOTE_USER" ! authentication data: VMS username
$!
$ request_uri = "/appl_cgi_path/CGI/environment/query?data"
$!
$! process Extract data from database
$!
$ run applsub_exe:retrievedata.exe
$!
$ exit

where you appear to be setting up symbols that will be used by retrievedata.exe. One is "request_uri" - should this be "request_url" and might it be the source of your failures?

[Willem Grooters]

Robert: Audit/alarm/enable=file=fail did the thrick to find out what was going on. See conclusion at end....
Jim: might be a typo in the description om ITRC, but the CGI scripts is the same on both nodes so that is not the problem. See conclusion.

[Willem Grooters]

Loginout fails to access:

_disk:[rootdir]

this is required since the procedure to be executed resides in

_disk:[rootdir.CGI.TMP]

This root directory has protection by ACL:

(ID=env_user,ACCESS=READ+WRITE+EXECUTE)
(ID=env_user,DEFAULT_PROTECTION=READ+WRITE+EXECUTE+DELETE)
(ID=APACHE$WWW,ACCESS=EXECUTE)

I added READ access to APACHE$WWW but that didn't make a difference.
Granting identifier ENV_USER to APACHE$WWW solved the problem!

I don't like the idea of APACHE$WWW having access to ALL files of this environment. READ+EXECUTE on all directories, or even EXECUTE only, should do the trick as well.