Permission issue on file WebSphere creates

[robbie...@gmail.com]

We have an issue for which we can think of a few workarounds, but we
don't like any of them. Here is the situation:

We have a servlet running on WebSphere that creates a PDF. We want to
serve the PDF up via the Apache server when the user clicks a link, but
QTMHHTTP does not have authority to it. In fact, only QEJBSVR has
authority to it.

Possible workarounds that we didn't like:
1) Create an empty dynamic web application, deploy the EAR and write
the PDFs into the WAR folder of the installed apps folder where
WebSphere can serve it from w/o any authority issues. Problems: a)
Someone could overlay the PDFs by installing a new ear. b) The
installed apps path changes with new versions of the app server. c) We
want Apache to serve the PDF and not WebSphere.

2) After writing the PDF to a neutral directory call a CL to grant
object authority to the PDF to the QTMHHTTP profile. Problems: a)
Performance is a concern. b) Security is a concern because the job with
have to run with near QSECOFR authority in order to grant access to
something that QEJBSVR owns.

3) Write the PDF to a neutral directory and when the user clicks a link
call a servlet that reads the PDF and outputs it to the browser.
Problems: a) Performance is slow on large PDFs. b) We also need to be
able to handle stream types other than PDFs (images, docs, etc.)

4) Use the os400.file.create.auth and os400.dir.create.auth
properties as posted to this group April 23, 2003 that grants *public
authority to anything WebSphere creates. Problems: a) Too much of a
security risk. b) Even in testing seemed to only work half the time
for some reason.

So back to square 1: Is there a way for Apache to serve something
WebSphere creates w/o having to call CLs to manipulate authorities or
locations? If not, is there a way to make WebSphere serve from a
directory outside of its installed apps path where it may have written
a file?

We'd be happy with either scenario, so long as it is straightforward.

Thanks in advance.

Rob Wilson

[walker.l2]

I'd go with option 2. I don't think you'll need 'near QSECOFR'
authority to do this. If WebSphere creates the PDF as QEJBSVR, then a
CL call from WebSphere (still running as QEJBSVR) should be able to
grant the necessary authority to QTMHHTTP.

Also, I don't think you'll experience any performance problems with
this (if you need to, you could code the CL call as a singleton, and
hold the command connection to the AS/400 open all the time your web
app is running). But of course the only way to know for sure would be
to try it...

Walker.

[Rob Wilson]

The CL would not run as QEJBSVR though. The application server runs as
QEJBSVR, but another profile has to be provided in order to call a CL
and that is wherein my problem lies. I'd really like an alternative
outside of the 4 listed if one is available. Thanks for your response,
Walker.

Rob

[walker.l2]

Rob,
You don't need another profile to run a CL command or program (at least
you don't under WAS 5.0); you can just do something like this:

com.ibm.as400.access.AS400 myAS400 = new AS400(); // Attaches to the
current AS/400 using the same profile as WebSphere
com.ibm.as400.access.CommandCall grantAuthorityCommand = new
CommandCall();
boolean successFlag = false;

myAS400.connectService(AS400.COMMAND); // Connects to the comand /
program request port
grantAuthorityCommand.setServer(myAS400); // Connect the commandcall
object to the as400
successFlag = grantAuthorityCommand.run("CHGAUT OBJ('path/mydoc.pdf')
USER(QTMHHTTP) DTAAUT(*R) OBJAUT(*OBJEXIST *OBJREF)"); // Run the
command
myAS400.disconnectService(AS400.COMMAND); // Tidy up
if (successFlag == false) {
System.err.println("Object authority not granted");
}

You will need to add some Exception handling and tweak the command and
error handling to your requirements, but this should do the trick.
Also, you might prefer to wrap the CL commands in a CL program and use
the ProgramCall class instead of the CommandCall class (this can make
testing simpler).

Walker.

[Rob Wilson]

When we tried as you say, we get this error message:

com.ibm.as400.access.AS400SecurityException: Password is *NONE.

We are running 5.1 Express with the latest version of the toolbox so
maybe that is the difference.

Thanks for your response.

[walker.l2]

Rob,
This is a nasty AS/400 'gotcha'. By default, QEJBSVR ships without a
password (hence the *NONE). If you get one of your System
Administrators to assign a password to QEJBSVR, and set it to never
expire, your problem will be solved. This shouldn't present any
security risk, since nobody will ever need to know what the password
actually is(our SysAdmins never even nothered to make a note of it),
and QEJBSVR should still be set so that it can't be used to sign on to
a terminal session.

Walker.

[Rob Wilson]

Walker,

Thank you very much for your advice. This solution should work out
great for us. It has been a pleasure.

Regards,

Rob Wilson

[walker.l2]

Rob,

Glad to be of help. (Thanks for letting me know that it worked for
you.)

Another solution might have been to run WAS under the QTMHHTTP profile
(you can do this from the Admin Console in 5.0 Base, presumably 5.1
Express supports it too). Personally I think the confusion this could
cause, and the security implications, outweigh the benefit - executing
the CL command seems the better option.

Walker.