Dirickson Steve wrote:

> Speaking from a position of profound ignorance, I'm guessing from the
> items mentioned that
> 1)      "MPED" provides remote execution of MPE commands

ah, yes, that's what i get for assuming :-)  yes, mped is delivered in
twoparts, an set of programs that live on a 3000 and a binary/program that
lives on an hp-ux box.  on the unix side, we also made an entry in
etc/services.  the unix user types "mpe <mpe server> <mpe command>"

> 2)      "MPED" logs on as MANAGER.SYS or some similar high-privilege
> level user

it's entirely up to you but i have created a user called (hehehe) 'mped'in
sys, homed to a 'mped' group.  this user's caps are: sf,ba,ph.  this
user is doing the executing of the commands received from the unix
system.

> 3)      "MPED" does not interact with the remote user to identify &
> authenticate that user

not that i can tell...

> 4)      Possibly as a result of #3, "MPED" does not use AIFCHANGELOGON
> to "become" some less-privileged user

i don't think so....

> If any of the above is valid, then one option might be to run "MPED" as
> some less-privileged user; another would be to ask Jim to implement an
> optional AIFCHANGELOGON capability to change to some other logon and
> environment, possibly based on input from the remote user and validated
> using info from AIFACCTGET.

if i understand what happens in the unix world with remsh and rexec
is they can create 'yes & no' lists.  ie, yes 'this' command is allowed
but no 'that' command is not.  incorporating this would be a 'jim' thing
since it's
his software.  aif:pe would also be a jim thing.  but lets just suppose
jim doesn't want to change his code...i'm left with trying to trap the
command *after* it leaves the mped program but *before* it
actually hits the ci -- a udc that (i don't think) can be written
short of the brute force method (ugh)           - d
--
Donna Garverick     Sr. System Programmer
925-210-6631        [log in to unmask]

>>>MY opinions, not Longs Drug Stores'<<<<