Permission issue on file WebSphere creates - Websphere

This is a discussion on Permission issue on file WebSphere creates - Websphere ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Permission issue on file WebSphere creates

  1. Permission issue on file WebSphere creates

    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


  2. Re: Permission issue on file WebSphere creates

    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.


  3. Re: Permission issue on file WebSphere creates

    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


  4. Re: Permission issue on file WebSphere creates

    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.


  5. Re: Permission issue on file WebSphere creates

    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.


  6. Re: Permission issue on file WebSphere creates

    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.


  7. Re: Permission issue on file WebSphere creates

    Walker,

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

    Regards,

    Rob Wilson


  8. Re: Permission issue on file WebSphere creates

    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.


+ Reply to Thread