Re: Qshell authority

This seems like a severe limitation, since normal users would never be able
to execute a java program interactively.  It seems the specific authority
required for QSH is *ALLOBJ.  Apparently the posts I have seen in this list
regarding suppression of QSH output, etc. really only is an issue if the
user has *ALLOBJ authority, and of course that will not be the environment
for end users in most organizations.  I guess I could write a server which
would accept requests and return responses on behalf of a client user, but
this sounds much like an HTTP server, and is a lot of work just to overcome
a security issue.

I've also tried CRTJVAPGM USRPRF(*OWNER) USEADPAUT(*YES) for my jar files,
but it doesn't seem to make any difference.

The joblog gives no hints as to the objects for which the user has
insufficient authority, but would it not be possible to grant specific
authorities if these objects could be identified?  Do you know which objects
these would include?

Thanks,
Shawn

----- Original Message -----
From: "Fred Kulack" <kulack@us.ibm.com>
To: <JAVA400-L@midrange.com>
Sent: Wednesday, March 21, 2001 9:56 AM
Subject: Re: Qshell authority


>
> On 03/20/2001 at 04:06:25 PM, "Shawn Church" <shawn@boxity.com> wrote:
> I normally execute QSH or RUNJVA within batch jobs having at least *PGMR
> class authority.  I now need to run a java program interactively within
> normal *USER authority jobs, and fail with the following exceptions:
>
> For QSH:
> MCH3601 Pointer not set for location referenced
> (No other messages are displayed)
>
> For RUNJVA:
> JVAB53A Unable to start Java shell, reason code 3401
>
> These commands are executed within a CL owned by QPGMR and using *OWNER
> adoptive authority, but QSH/STRQSH/JAVA/RUNJVA apparently do not honor
> program adoptive authority, but rather use the current user profile for
the
> job.  I am at V4R5, with cumulative PTF level of 00294.  I have tried
> several different ways to work around the problem, but to no avail.
>
> I haven't found any APARs relating to this, and I don't see any
discussions
> of authority in the Qshell documentation.
>
> Any advice is appreciated.
> --- end of excerpt ---
>
> Sorry, you need to change your design.
> IFS doesn't support adopted authority.
> And thus, you'll have a real difficult time getting
> Java and/or Qshell to support it.
>
> I recommend adopting authority to someone that
> has enough authority to swap user profiles to
> a specific user id associated only with your application.
> Then, grant or revoke appropriate authorities to that
> specific user or objects for that user.
>
>
> "The stuff we call "software" is not like anything that human society
>   is used to thinking about. Software is something like a machine, and
>   something like mathematics, and something like language, and
>   something like thought, and art, and information...
>   but software is not in fact any of those other things."
> Bruce Sterling - The Hacker Crackdown
>
> Fred A. Kulack  -  AS/400e  Java and Java DB2 access, Jdbc, JTA, etc...
> IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
> mailto:kulack@us.ibm.com   Personal: mailto:kulack@bresnanlink.net
> AOL Instant Messenger: Home:FKulack  Work:FKulackWrk
>
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to JAVA400-L@midrange.com.
> | To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: joe@zappie.net
> +---
>

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---